6.3 MiB
6.3 MiB
id,task_title,comment_text,date_created,AuthorPHID,TaskPHID,comment_type,text_for_analysis,cleaned_messages,priority,priority_score,date_closed,CloserPHID,status,time_flag,source,phase,author_closer,same_author,week_index,http_flag,olmo_cleaned_sentences,resolution_outcome,verification_sample,cleaned_sentences,human_label,isEdgeCase,ECRationale 1964,"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",1371574560,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_description,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1371574643,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal,BUG REPRODUCTION,x,"provides link to example error where bug is reproduced, could also be INVESTIGATION AND EXPLORATION" 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,x,Describes observed bug behavior as severe 6365,VisualEditor: Pasting text into VE from external text processor removes newlines,"Change 86664 merged by jenkins-bot: Rich paste https://gerrit.wikimedia.org/r/86664",1385500082,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Change 86664 merged by jenkins-bot: Rich paste https://gerrit.wikimedia.org/r/86664","Change 86664 merged by jenkins-bot: Rich paste GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,21,NA,['Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL'],NA,1,Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL,TASK PROGRESS,x,Not quite action on issue but it is an update of how the work is going 6392,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.",INVESTIGATION AND EXPLORATION,x,"I'm not sure if this falls into SOLUTION DISCUSSION though, primarily concerned with figuring out the behavior of the bug " 6394,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,Neither kww or the ip who can reproduce this have noted their system.,BUG REPRODUCTION,x,Could also be Social; though it's a social comment focused on bug reproduction 7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,This is not how OpenOffice or Word works.,EXPECTED BEHAVIOR,x,I think this makes sense because it's describing motivating examples of expected behavior 7037,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).",EXPECTED BEHAVIOR,x,I think that this is clearly describing a motivating example of expected functionality -- could also be motivational or social. 7037,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",EXPECTED BEHAVIOR,x,I think that this is clearly describing a motivating example of expected functionality -- could also be motivational or social. 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow).",SOLUTION DISCUSSION,x,"I think that this is a pretty direct discussion of a possible solution, something that hasn't happened yet but is also not explicitly planned" 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"The re-ordered tabs and section edit links, so that the VE tab is second?",SOLUTION DISCUSSION,x,"I think these are all solution discussions because though they are framed as questions, they are specifically asking about facets of a given solution" 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.",EXPECTED BEHAVIOR,x,"Once again, describing extant software behavior as the expected behavior of a given feature " 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.",MOTIVATION,x,"In this case, kind of an anti-motivation" 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,And we're currently duplicating this internal logic at the cost of decentralisation.,INVESTIGATION AND EXPLORATION,x, 14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,to ''URL making the request SSL/TLS protected for all users.,SOCIAL CONVERSATION,x,Seems like small talk when decontextualized 14319,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"(In reply to comment #1) > A related improvement would be to use the secure API endpoint when the user > is using https on the mediawiki site. Only if it works. ;-)",1379997214,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"(In reply to comment #1) > A related improvement would be to use the secure API endpoint when the user > is using https on the mediawiki site. Only if it works. ;-)","(In reply to comment #1) QUOTE QUOTE Only if it works. ;-)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,;-),SOCIAL CONVERSATION,, 15546,Wikidata.org is using the SSL certificate for *.wikimedia.org,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. Closing too, thanks for the ping.",1354281045,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. Closing too, thanks for the ping.","RT #3803 resolved, URL merged. Closing too, thanks for the ping.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-39,TRUE,"['RT #3803 resolved, URL merged.', 'Closing too, thanks for the ping.']",NA,1,"RT #3803 resolved, URL merged.",TASK PROGRESS,x,Update on relevant work to the comment 15551,Wikidata.org is using the SSL certificate for *.wikimedia.org,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.","<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.,SOLUTION DISCUSSION,x,"Thought about this being investigation and exploration but it's explicitly about the solution working on the pages - so I think it's discussion,. " 15556,Wikidata.org is using the SSL certificate for *.wikimedia.org,Doesn't seem to have fixed it... Or just hasn't been deployed.,1351377062,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Doesn't seem to have fixed it... Or just hasn't been deployed.,Doesn't seem to have fixed it... Or just hasn't been deployed.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[""Doesn't seem to have fixed it... Or just hasn't been deployed.""]",NA,1,Doesn't seem to have fixed it... Or just hasn't been deployed.,OBSERVED BUG BEHAVIOR,x,I think this is still describing the persistence of buggy behavior but could also be something else 16733,MWHttpRequest may have to require_once() GlobalFunctions.php,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,1321644785,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-93,TRUE,"[""You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?"", 'quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.']",NA,1,quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,INVESTIGATION AND EXPLORATION,X,"ITS HARD BECAUSE IT SEEMS LIKE A DIRECTIVE, BUT I THINK ULTIMATELY THIS IS STILL A QUESTION TRYING TO FIGURE OUT THE USE PATTERN THAT GENERATES THE BUG " 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,This is using MediaWiki 1.18.0.,BUG REPRODUCTION,X,"I THINK THE INFORMATION PROVIDED IS CLEARLY FOR REPRODUCTION PURPOSES, BUT ALSO COULD BE INVESTIGATION " 16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).,ACTION ON ISSUE,X,"GIVEN THAT THE COMMENT PRIMARILY FOCUSES ON THE ISSUE OPEN/CLOSE STATUS, I THINK THAT IT IS MORE ACTION ON ISSUE THAN IT IS FUTURE WORK OR ANYTHING " 16860,NewUserMessage extensions breaks login,"**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?",1337632645,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?","**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,"['**AzianAlex** wrote:\n\nWorks fine for me too.', 'Have you tried clearing your cache?']",NA,1,**AzianAlex** wrote:\n\nWorks fine for me too.,SOLUTION USAGE,X,"ANTI-REPRODUCTION, TESTING AND USAGE OF SOLUTION" 16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks","**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,**vivekee047** wrote:\n\nThis works fine for me.,SOLUTION USAGE,X, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.",TASK PROGRESS,X,CONTAINS BOTH BUG BEHAVIOR AND SOLUTION DISCUSSION BUT I THINK THAT THE SOLUTION DISCUSSION IS A BIT MORE SALIENT 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And this bug sitting here isn't going to change that schedule.,ISSUE CONTENT MANAGEMENT,X,REFERENCE TO THE ISSUE 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,See also the tracking bug about secure access (bug 27946).,ISSUE CONTENT MANAGEMENT,X,SEEMS TO BE REDIRECTING DISCUSSION TO EXTERNAL SPACE- NOT NECESSARILY DISCUSSING ISSUE ACTION THOUGH 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?,SOLUTION USAGE,X,COULD ALSO BE INVESTIGATION 17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: Still reproducible at URL When I change the width: URL then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,"This may be related to bug 13493 (""Can\",INVESTIGATION AND EXPLORATION,X,ISSUE-CONTENT-Y BUT ULTIMATELY IS CONJECTURE ABOUT MECHANISM 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.",POTENTIAL NEW ISSUES AND REQUESTS,X,ALSO A LITTLE BIT OF DISCUSSION AROUND THE MANAGEMENT OF THE SOLUTION ETC. 1964,"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",1371574560,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_description,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1371574643,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.",OBSERVED BUG BEHAVIOR,, 1965,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting"," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",1371574643,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_subcomment," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%"," %%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,['\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%'],NA,1,\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%,ACTION ON ISSUE,, 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,VisualEditor: Pasting text into VE from external text processor removes newlines.,OBSERVED BUG BEHAVIOR,, 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).",BUG REPRODUCTION,, 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,Newline is not copied in any of the cases.,OBSERVED BUG BEHAVIOR,, 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,The problem has also been tested by trying to copy-paste html text from chrome itself.,BUG REPRODUCTION,, 6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: Win7 X64 Google Chrome 29.0.1547.62 m Steps to reproduce: Open a page Edit it in VE Copy-paste the following text: a b c d e Expected output: a b c d e Actual output: abcde The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,Newline is not copied.,OBSERVED BUG BEHAVIOR,, 6366,VisualEditor: Pasting text into VE from external text processor removes newlines,Works with gedit & chrome with the rich paste patch.,1381157678,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,Works with gedit & chrome with the rich paste patch.,Works with gedit & chrome with the rich paste patch.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,['Works with gedit & chrome with the rich paste patch.'],NA,1,Works with gedit & chrome with the rich paste patch.,EXPECTED BEHAVIOR,, 6367,VisualEditor: Pasting text into VE from external text processor removes newlines,"Change 86664 had a related patch set uploaded by Esanders: Rich paste https://gerrit.wikimedia.org/r/86664",1381157509,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Change 86664 had a related patch set uploaded by Esanders: Rich paste https://gerrit.wikimedia.org/r/86664","Change 86664 had a related patch set uploaded by Esanders: Rich paste GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,['Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL'],NA,1,Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL,TASK PROGRESS,, 6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.,TESTING,, 6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.",TESTING,, 6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.",TESTING,, 6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook Using kwrite: Tested with \n \r and \r\n end of lines and it makes no difference. Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: a b c d e None of it makes the slightest bit of difference. URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,URL is the copy from comment 0,INVESTIGATION AND EXPLORATION,, 6380,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** CODE **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE.",OBSERVED BUG BEHAVIOR,, 6380,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** CODE **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\",MOTIVATION,, 6380,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** `kwwilliams` **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE./n/n**Author:** CODE **Description:** When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with <div class=""ve-ce-protectedNode""> and </div>.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,ve-ce-protectedNode,NA,, 6381,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","(In reply to This, that and the other from comment #13) > As it stands, this is a dupe of bug 52141. I've put back the original bug > summary; it seems to me that WONTFIX is the appropriate resolution for this > bug. Agreed.",1403741232,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to This, that and the other from comment #13) > As it stands, this is a dupe of bug 52141. I've put back the original bug > summary; it seems to me that WONTFIX is the appropriate resolution for this > bug. Agreed.","(In reply to This, that and the other from comment #13) QUOTE QUOTE QUOTE Agreed.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,51,NA,"['(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed.']",NA,1,"(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed.",SOCIAL CONVERSATION,, 6382,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,"As it stands, this is a dupe of bug 52141.",ISSUE CONTENT MANAGEMENT,, 6382,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.,ACTION ON ISSUE,, 6383,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","James, that is bug 52141. This bug was about a specific problem with the existing code.",1383886236,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"James, that is bug 52141. This bug was about a specific problem with the existing code.","James, that is bug 52141. This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,"James, that is bug 52141.",ISSUE CONTENT MANAGEMENT,, 6383,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","James, that is bug 52141. This bug was about a specific problem with the existing code.",1383886236,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"James, that is bug 52141. This bug was about a specific problem with the existing code.","James, that is bug 52141. This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,This bug was about a specific problem with the existing code.,MOTIVATION,, 6384,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",1381342100,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,"['Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.']",NA,1,"Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",ISSUE CONTENT MANAGEMENT,, 6385,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.",BUG REPRODUCTION,, 6385,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,The toolbar is another way to override the protectedNode.,WORKAROUNDS,, 6385,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.",OBSERVED BUG BEHAVIOR,, 6385,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. This template is also being used to create a 'pre' text area on URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,This template is also being used to create a 'pre' text area on\nURL,POTENTIAL NEW ISSUES AND REQUESTS,, 6386,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: Note URL , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.",INVESTIGATION AND EXPLORATION,, 6386,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: Note URL , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,We really need to have a method to shield articles from VE.,MOTIVATION,, 6386,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: Note URL , where another 26,000 articles that VE mutilates have been identified. We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",SOLUTION USAGE,, 6387,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.,TESTING,, 6387,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,"At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL",OBSERVED BUG BEHAVIOR,, 6388,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: (In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.",MOTIVATION,, 6388,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: (In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",MOTIVATION,, 6388,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: (In reply to comment #6) > On the wider point, it's not clear if there's an actual long-term need for a > proper VE-prevention system (or if it's all solvable with a few quick fixes > of > bad wikitext), but if there is, we should build a proper one, not rely on a > hack that might break. What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: (In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE What's unclear about that? I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?,SOCIAL CONVERSATION,, 6389,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) QUOTE QUOTE QUOTE In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\",INVESTIGATION AND EXPLORATION,, 6389,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) QUOTE QUOTE QUOTE In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,s not clear if there\,NA,, 6389,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) > The div has been removed, so people need to look at > https://en.wikipedia.org/w/index. > php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) QUOTE QUOTE QUOTE In this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the <ref> was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",MOTIVATION,, 6390,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632",1378322920,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632","**kwwilliams** wrote: The div has been removed, so people need to look at URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL']",NA,1,"**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL",OBSERVED BUG BEHAVIOR,, 6391,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: (In reply to comment #3) > According to the documentation, the div is only meant to block editing to a > section of a page (although that section can be the whole text), so adding > text > before is correct, likewise you should be able to add text after the /div. It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: (In reply to comment #3) > According to the documentation, the div is only meant to block editing to a > section of a page (although that section can be the whole text), so adding > text > before is correct, likewise you should be able to add text after the /div. It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote: (In reply to comment #3) QUOTE QUOTE QUOTE QUOTE It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour.,OBSERVED BUG BEHAVIOR,, 6391,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: (In reply to comment #3) > According to the documentation, the div is only meant to block editing to a > section of a page (although that section can be the whole text), so adding > text > before is correct, likewise you should be able to add text after the /div. It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: (In reply to comment #3) > According to the documentation, the div is only meant to block editing to a > section of a page (although that section can be the whole text), so adding > text > before is correct, likewise you should be able to add text after the /div. It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote: (In reply to comment #3) QUOTE QUOTE QUOTE QUOTE It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,I agree that it's not technically wrong.,SOCIAL CONVERSATION,, 6392,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,The editing templates within the div does sound like a bug though.,SOCIAL CONVERSATION,, 6392,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. The editing templates within the div does sound like a bug though. If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.,INVESTIGATION AND EXPLORATION,, 6393,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.,TESTING,, 6393,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"To be clear, we are still prevented from editing the text.",OBSERVED BUG BEHAVIOR,, 6393,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: Firefox 23.0.1 on Windows 7. To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"We are not prevented from editing templates, and we can insert text before div.",OBSERVED BUG BEHAVIOR,, 6394,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,The original person to report this noted that they were using Chrome 29 on Windows 7.,BUG REPRODUCTION,, 6394,"VisualEditor: <div class=""ve-ce-protectedNode""> not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. I have been unable to reproduce this in Firefox 23 on Linux. Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,I have been unable to reproduce this in Firefox 23 on Linux.,BUG REPRODUCTION,, 7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,VisualEditor: Backspace should not delete list and line in same action.,EXPECTED BEHAVIOR,, 7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.",EXPECTED BEHAVIOR,, 7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE **Description:** Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,VisualEditor will completely delete the line itself and move the text to the end of the previous line.,OBSERVED BUG BEHAVIOR,, 7038,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.",EXPECTED BEHAVIOR,, 7038,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD><EFBFBD><EFBFBD>no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden <20><><EFBFBD>\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",EXPECTED BEHAVIOR,, 7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?","Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n| <ol><li><p>|</p></li><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD>\xa0backspace at the cursor position indicated should convert the document into:\n\n| <p>|</p><ol><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD> with the initial <p> being a slug.', 'For nested list items we should pop to the next level:\n\n| <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol>\n\n->\n\n\n| <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol>\n\nI think?']",NA,1,Agreed.,SOCIAL CONVERSATION,, 7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?","Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n| <ol><li><p>|</p></li><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD>\xa0backspace at the cursor position indicated should convert the document into:\n\n| <p>|</p><ol><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD> with the initial <p> being a slug.', 'For nested list items we should pop to the next level:\n\n| <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol>\n\n->\n\n\n| <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol>\n\nI think?']",NA,1,For\n\n| <ol><li><p>|</p></li><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD>\xa0backspace at the cursor position indicated should convert the document into:\n\n| <p>|</p><ol><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD> with the initial <p> being a slug.,EXPECTED BEHAVIOR,, 7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?","Agreed. For | <ol><li><p>|</p></li><li><p>Foo</p></li></ol> <0A><><EFBFBD><EFBFBD><EFBFBD>backspace at the cursor position indicated should convert the document into: | <p>|</p><ol><li><p>Foo</p></li></ol> <0A><><EFBFBD> with the initial <p> being a slug. For nested list items we should pop to the next level: | <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol> -> | <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol> I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n| <ol><li><p>|</p></li><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD>\xa0backspace at the cursor position indicated should convert the document into:\n\n| <p>|</p><ol><li><p>Foo</p></li></ol>\n\n<><6E><EFBFBD> with the initial <p> being a slug.', 'For nested list items we should pop to the next level:\n\n| <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol>\n\n->\n\n\n| <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol>\n\nI think?']",NA,1,For nested list items we should pop to the next level:\n\n| <ol><li><p>Foo</p></li><li><ol><li><p>|</p></li><li><p>Foo</p></li></ol></li></ol>\n\n->\n\n\n| <ol><li><p>Foo</p></li><li><p>|</p></li><li><ol><li><p>Foo</p></li></ol></li></ol>\n\nI think?,EXPECTED BEHAVIOR,, 7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.",EXPECTED BEHAVIOR,, 7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,Users are requesting VE August update (URL to be deployed in on hewiki.,MOTIVATION,, 7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL,OBSERVED BUG BEHAVIOR,, 7046,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Finally done; sorry for the delay.,1381515689,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Finally done; sorry for the delay.,Finally done; sorry for the delay.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,['Finally done; sorry for the delay.'],NA,1,Finally done; sorry for the delay.,SOCIAL CONVERSATION,, 7047,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 merged by Reedy: Switch VisualEditor to secondary status on hewiki https://gerrit.wikimedia.org/r/87645",1381515513,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 87645 merged by Reedy: Switch VisualEditor to secondary status on hewiki https://gerrit.wikimedia.org/r/87645","Change 87645 merged by Reedy: Switch VisualEditor to secondary status on hewiki GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,['Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL'],NA,1,Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL,TASK PROGRESS,, 7048,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #14) > Change 87645 had a related patch set uploaded by Jforrester: > Switch VisualEditor to secondary status on hewiki > > https://gerrit.wikimedia.org/r/87645 Will try to schedule this soon.",1380938287,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #14) > Change 87645 had a related patch set uploaded by Jforrester: > Switch VisualEditor to secondary status on hewiki > > https://gerrit.wikimedia.org/r/87645 Will try to schedule this soon.","(In reply to comment #14) QUOTE QUOTE QUOTE QUOTE Will try to schedule this soon.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,['(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon.'],NA,1,(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon.,FUTURE PLANS,, 7049,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 had a related patch set uploaded by Jforrester: Switch VisualEditor to secondary status on hewiki https://gerrit.wikimedia.org/r/87645",1380938237,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 87645 had a related patch set uploaded by Jforrester: Switch VisualEditor to secondary status on hewiki https://gerrit.wikimedia.org/r/87645","Change 87645 had a related patch set uploaded by Jforrester: Switch VisualEditor to secondary status on hewiki GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,['Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL'],NA,1,Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL,TASK PROGRESS,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.",SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,I think that it\,SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"t come to ""a decision"".",SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,:-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.,SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?",INVESTIGATION AND EXPLORATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).",INVESTIGATION AND EXPLORATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,But I see your point.,SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,Not sure.,SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis.",SOLUTION DISCUSSION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this.",SOCIAL CONVERSATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.",INVESTIGATION AND EXPLORATION,, 7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) > Thanks for adding the welcome message. > > I know there are discussions regarding these changes[1], but the change of > the tab order (Edit and Edit source) is important for he wikipedia and Erik > isn't totally against it [only ambivalent] :) > > [1] > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ > 000419.html To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( > Since VE is enabled only in the main NS and user NS, for editors who also > edit in other namespaces, addition of the VE edit tab ""in the middle"" may > cause confusion. That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. > For consistency the edit source option should be alway the first > option [in order], while VE edit should be second. An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( QUOTE QUOTE QUOTE That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. QUOTE QUOTE An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",WORKAROUNDS,, 7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,Thanks for adding the welcome message.,SOCIAL CONVERSATION,, 7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,"I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\",SOLUTION USAGE,, 7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. ---- [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,in the middle,NA,, 7052,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 77269 merged by jenkins-bot: Enable VisualEditor beta welcome notice for all wikis https://gerrit.wikimedia.org/r/77269",1378927706,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 77269 merged by jenkins-bot: Enable VisualEditor beta welcome notice for all wikis https://gerrit.wikimedia.org/r/77269","Change 77269 merged by jenkins-bot: Enable VisualEditor beta welcome notice for all wikis GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,10,NA,['Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL'],NA,1,Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL,TASK PROGRESS,, 7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,[Sorry for the delay in responding.],SOCIAL CONVERSATION,, 7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,The beta welcome message is now queued up to go out on all wikis with the next release when available.,SOLUTION DISCUSSION,, 7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,Sorry.,SOCIAL CONVERSATION,, 7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] The beta welcome message is now queued up to go out on all wikis with the next release when available. We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer.",TASK PROGRESS,, 7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.",SOLUTION DISCUSSION,, 7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,Please let us know when this change is planned for deployment.,TASK PROGRESS,, 7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"There is is large support for the change in the village pump. https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,There is is large support for the change in the village pump.,MOTIVATION,, 7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"There is is large support for the change in the village pump. https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,URL,NA,, 7056,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",All of these,1377020909,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,All of these,All of these,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,7,NA,['All of these'],NA,1,All of these,SOCIAL CONVERSATION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Hey,\n\nWhich of the bits of the update do you mean?",SOCIAL CONVERSATION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,1,NA,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,2,NA,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Giving a welcome message when you open VisualEditor for the first time?,SOLUTION DISCUSSION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,3,NA,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?",SOLUTION DISCUSSION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,4,NA,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?",SOLUTION DISCUSSION,x, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,5,NA,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Removing the animation on section edit links?,SOLUTION DISCUSSION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,All of these?,SOCIAL CONVERSATION,, 7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.","Hey, Which of the bits of the update do you mean? 1. The re-ordered tabs and section edit links, so that the VE tab is second? 2. Giving a welcome message when you open VisualEditor for the first time? 3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? 4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? 5. Removing the animation on section edit links? All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Items 4 and 5 are already done.,TASK PROGRESS,, 7058,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",is there any progress with the request?,1376848108,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,is there any progress with the request?,is there any progress with the request?,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,6,NA,['is there any progress with the request?'],NA,1,is there any progress with the request?,TASK PROGRESS,, 7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,1375862146,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,Gerrit change 77269 will handle part of this.,TASK PROGRESS,, 7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,1375862146,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,They were just waiting on translations of the messages before enabling it.,SOCIAL CONVERSATION,, 7060,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",added in the url field.,1375792847,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,added in the url field.,added in the url field.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,['added in the url field.'],NA,1,added in the url field.,SOCIAL CONVERSATION,, 7061,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #0) > Users are requesting VE August update > (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to > be deployed in on hewiki. Please provide a link to these requests, if possible.",1375791382,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #0) > Users are requesting VE August update > (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to > be deployed in on hewiki. Please provide a link to these requests, if possible.","(In reply to comment #0) QUOTE QUOTE QUOTE Please provide a link to these requests, if possible.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,5,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible.']",NA,1,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible.",ISSUE CONTENT MANAGEMENT,, 7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Please mark the targeted milestone when it is known. Thanks,1375721827,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Please mark the targeted milestone when it is known. Thanks,Please mark the targeted milestone when it is known. Thanks,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,Please mark the targeted milestone when it is known.,ISSUE CONTENT MANAGEMENT,, 7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Please mark the targeted milestone when it is known. Thanks,1375721827,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Please mark the targeted milestone when it is known. Thanks,Please mark the targeted milestone when it is known. Thanks,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,Thanks,SOCIAL CONVERSATION,, 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,mw.hook listeners for GuidedTour for shouldSkip.,EXPECTED BEHAVIOR,, 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,Investigate how mw.hook could be useful for GuidedTour.,INVESTIGATION AND EXPLORATION,, 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,One idea is subscribing to state changes for shouldSkip.,FUTURE PLANS,, 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).",FUTURE PLANS,, 9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). -------------------------- **Version**: master **Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,--------------------------\n**Version**: master\n**Severity**: enhancement,FUTURE PLANS,, 9572,mw.hook listeners for GuidedTour for shouldSkip,"Change 116228 merged by jenkins-bot: Refactor and add non-linear tours, with tests https://gerrit.wikimedia.org/r/116228",1402332994,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"Change 116228 merged by jenkins-bot: Refactor and add non-linear tours, with tests https://gerrit.wikimedia.org/r/116228","Change 116228 merged by jenkins-bot: Refactor and add non-linear tours, with tests GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,49,NA,"['Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL",TASK PROGRESS,, 9573,mw.hook listeners for GuidedTour for shouldSkip,"Change 116228 had a related patch set uploaded by Mattflaschen: WIP: Refactor and add non-linear tours, with tests https://gerrit.wikimedia.org/r/116228",1397707892,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"Change 116228 had a related patch set uploaded by Mattflaschen: WIP: Refactor and add non-linear tours, with tests https://gerrit.wikimedia.org/r/116228","Change 116228 had a related patch set uploaded by Mattflaschen: WIP: Refactor and add non-linear tours, with tests GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,41,NA,"['Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL",TASK PROGRESS,, 9574,mw.hook listeners for GuidedTour for shouldSkip,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,This is done for VisualEditor.,TASK PROGRESS,, 9574,mw.hook listeners for GuidedTour for shouldSkip,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,"I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",ISSUE CONTENT MANAGEMENT,, 9575,mw.hook listeners for GuidedTour for shouldSkip,I'm working on a change set right now that uses mw.hook for VE like this.,1373067339,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,I'm working on a change set right now that uses mw.hook for VE like this.,I'm working on a change set right now that uses mw.hook for VE like this.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,0,NA,"[""I'm working on a change set right now that uses mw.hook for VE like this.""]",NA,1,I'm working on a change set right now that uses mw.hook for VE like this.,TASK PROGRESS,, 11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,VisualEditor: Suppression of Cite error in templates still paints a phantom.,OBSERVED BUG BEHAVIOR,, 11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.,OBSERVED BUG BEHAVIOR,, 11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.",OBSERVED BUG BEHAVIOR,, 11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,See screenshot.,INVESTIGATION AND EXPLORATION,, 11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227},OBSERVED BUG BEHAVIOR,, 11494,VisualEditor: Suppression of Cite error in templates still paints a phantom,I believe that this has been fixed for some time; I cannot replicate now.,1392426157,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-v6t7ev5julnky6rafmtd,task_subcomment,I believe that this has been fixed for some time; I cannot replicate now.,I believe that this has been fixed for some time; I cannot replicate now.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,32,NA,['I believe that this has been fixed for some time; I cannot replicate now.'],NA,1,I believe that this has been fixed for some time; I cannot replicate now.,BUG REPRODUCTION,, 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.,OBSERVED BUG BEHAVIOR,, 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.",EXPECTED BEHAVIOR,, 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.",SOLUTION USAGE,, 12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,Force HTTPS for /token if the Consumer is not using an RSA key.,EXPECTED BEHAVIOR,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).",OBSERVED BUG BEHAVIOR,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,--------------------------\n**Version**: master\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,We currently don't require HTTPS for the consumer to get the authorization token.,INVESTIGATION AND EXPLORATION,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.",INVESTIGATION AND EXPLORATION,, 13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. rfc5849 - 2.3 says that: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.",INVESTIGATION AND EXPLORATION,, 13804,Force HTTPS for /token if the Consumer is not using an RSA key,"Change 85218 merged by jenkins-bot: Use HTTPS for Special:MWOAuth/token https://gerrit.wikimedia.org/r/85218",1380396294,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"Change 85218 merged by jenkins-bot: Use HTTPS for Special:MWOAuth/token https://gerrit.wikimedia.org/r/85218","Change 85218 merged by jenkins-bot: Use HTTPS for Special:MWOAuth/token GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,4,TRUE,['Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL'],NA,1,Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL,TASK PROGRESS,, 13805,Force HTTPS for /token if the Consumer is not using an RSA key,"Change 85218 had a related patch set uploaded by Anomie: Use HTTPS for Special:MWOAuth/token https://gerrit.wikimedia.org/r/85218",1379691008,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"Change 85218 had a related patch set uploaded by Anomie: Use HTTPS for Special:MWOAuth/token https://gerrit.wikimedia.org/r/85218","Change 85218 had a related patch set uploaded by Anomie: Use HTTPS for Special:MWOAuth/token GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,3,TRUE,['Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL'],NA,1,Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL,TASK PROGRESS,, 13806,Force HTTPS for /token if the Consumer is not using an RSA key,"(In reply to comment #0) > However, if the Consumer is using an RSA key, then the authorization token's > secret isn't used, so the security isn't affected by not using SSL for the > /token call. What about the token credentials returned in the response? Those are still plain text.",1379690874,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"(In reply to comment #0) > However, if the Consumer is using an RSA key, then the authorization token's > secret isn't used, so the security isn't affected by not using SSL for the > /token call. What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0) QUOTE QUOTE QUOTE What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?,INVESTIGATION AND EXPLORATION,, 13806,Force HTTPS for /token if the Consumer is not using an RSA key,"(In reply to comment #0) > However, if the Consumer is using an RSA key, then the authorization token's > secret isn't used, so the security isn't affected by not using SSL for the > /token call. What about the token credentials returned in the response? Those are still plain text.",1379690874,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"(In reply to comment #0) > However, if the Consumer is using an RSA key, then the authorization token's > secret isn't used, so the security isn't affected by not using SSL for the > /token call. What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0) QUOTE QUOTE QUOTE What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,Those are still plain text.,INVESTIGATION AND EXPLORATION,, 14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).,OBSERVED BUG BEHAVIOR,, 14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.",OBSERVED BUG BEHAVIOR,, 14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When not having the extension active, the result is made to api.flickr.com and works as expected.",OBSERVED BUG BEHAVIOR,, 14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.",INVESTIGATION AND EXPLORATION,, 14315,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,1389059684,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,18,TRUE,"[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,It seems Flickr changed how they handle HTTPS and there is no redirect now.,INVESTIGATION AND EXPLORATION,, 14315,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,1389059684,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,18,TRUE,"[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,Can't reproduce this.,BUG REPRODUCTION,, 14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.,INVESTIGATION AND EXPLORATION,, 14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,URL redirects to URL which causes the XHR request to hang/fail.,INVESTIGATION AND EXPLORATION,, 14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?',WORKAROUNDS,, 14317,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",1381880122,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.","The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,6,TRUE,"['The bug that we decided this duplicated seemed similar at the time, but it is actually very different.']",NA,1,"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",ISSUE CONTENT MANAGEMENT,, 14318,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)," *** This bug has been marked as a duplicate of bug 42468 ***",1381426891,PHID-USER-edlps6xg553cjlnvd4ao,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment," *** This bug has been marked as a duplicate of bug 42468 ***"," *** This bug has been marked as a duplicate of bug 42468 ***",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,['\n\n*** This bug has been marked as a duplicate of bug 42468 ***'],NA,1,\n\n*** This bug has been marked as a duplicate of bug 42468 ***,ISSUE CONTENT MANAGEMENT,, 14319,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"(In reply to comment #1) > A related improvement would be to use the secure API endpoint when the user > is using https on the mediawiki site. Only if it works. ;-)",1379997214,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"(In reply to comment #1) > A related improvement would be to use the secure API endpoint when the user > is using https on the mediawiki site. Only if it works. ;-)","(In reply to comment #1) QUOTE QUOTE Only if it works. ;-)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.,SOCIAL CONVERSATION,, 14320,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,1379948656,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,3,TRUE,['A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.'],NA,1,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,FUTURE PLANS,, 15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,Wikidata.org is using the SSL certificate for *.wikimedia.org.,INVESTIGATION AND EXPLORATION,, 15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.",OBSERVED BUG BEHAVIOR,, 15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org Reedy says this is RT #3803, creating bug here so no one else does. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 15542,Wikidata.org is using the SSL certificate for *.wikimedia.org,Verified in Wikidata demo time,1378307160,PHID-USER-ydl4ek3zzlyuz7f7upgt,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Verified in Wikidata demo time,Verified in Wikidata demo time,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,1,TRUE,['Verified in Wikidata demo time'],NA,1,Verified in Wikidata demo time,BUG REPRODUCTION,, 15543,Wikidata.org is using the SSL certificate for *.wikimedia.org,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA Verify return code: 0 (ok)",1366938159,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA Verify return code: 0 (ok)","openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA Verify return code: 0 (ok)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\n\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA\n\n Verify return code: 0 (ok)']",NA,1,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\n\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA\n\n Verify return code: 0 (ok)",BUG REPRODUCTION,, 15544,Wikidata.org is using the SSL certificate for *.wikimedia.org,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",1366907051,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?","dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?']",NA,1,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",CONTRIBUTION AND COMMITMENT ,, 15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.","(In reply to comment #12) QUOTE QUOTE IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\,INVESTIGATION AND EXPLORATION,, 15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.","(In reply to comment #12) QUOTE QUOTE IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, 15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.","(In reply to comment #12) QUOTE QUOTE IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, 15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) > RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. > Closing too, thanks for the ping. IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.","(In reply to comment #12) QUOTE QUOTE IMHO the diff doesn't look like a fix :( If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: $ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 CONNECTED(00000003) depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA ^^^ This is wrong. It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. --- Server certificate -----BEGIN CERTIFICATE----- [...cut...] -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 --- No client certificate CA names sent --- SSL handshake has read 3159 bytes and written 542 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA [...cut...] Verify return code: 21 (unable to verify the first certificate) --- QUIT DONE $ Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, 15546,Wikidata.org is using the SSL certificate for *.wikimedia.org,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. Closing too, thanks for the ping.",1354281045,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. Closing too, thanks for the ping.","RT #3803 resolved, URL merged. Closing too, thanks for the ping.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-39,TRUE,"['RT #3803 resolved, URL merged.', 'Closing too, thanks for the ping.']",NA,1,"Closing too, thanks for the ping.",ACTION ON ISSUE,, 15547,Wikidata.org is using the SSL certificate for *.wikimedia.org,Is this still open?,1354271269,PHID-USER-o4wy22wrannrbargenyn,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Is this still open?,Is this still open?,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,['Is this still open?'],NA,1,Is this still open?,ISSUE CONTENT MANAGEMENT,, 15548,Wikidata.org is using the SSL certificate for *.wikimedia.org,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",1353704583,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.","I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-40,TRUE,"['I see this bug is now tagged with the ""shell"" keyword.', 'I wonder if it should actually be tagged with the ""ops"" keyword instead.']",NA,1,"I see this bug is now tagged with the ""shell"" keyword.",ISSUE CONTENT MANAGEMENT,, 15548,Wikidata.org is using the SSL certificate for *.wikimedia.org,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",1353704583,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.","I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-40,TRUE,"['I see this bug is now tagged with the ""shell"" keyword.', 'I wonder if it should actually be tagged with the ""ops"" keyword instead.']",NA,1,"I wonder if it should actually be tagged with the ""ops"" keyword instead.",ISSUE CONTENT MANAGEMENT,, 15549,Wikidata.org is using the SSL certificate for *.wikimedia.org,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA --- Therefore: $ curl -v https://www.wikidata.org * About to connect() to www.wikidata.org port 443 (#0) * Trying 2620:0:861:ed1a::12... * connected [...cut...] * SSLv3, TLS alert, Server hello (2): * SSL certificate problem: unable to get local issuer certificate * Closing connection #0",1353416642,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA --- Therefore: $ curl -v https://www.wikidata.org * About to connect() to www.wikidata.org port 443 (#0) * Trying 2620:0:861:ed1a::12... * connected [...cut...] * SSLv3, TLS alert, Server hello (2): * SSL certificate problem: unable to get local issuer certificate * Closing connection #0","The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA --- Therefore: $ curl -v URL * About to connect() to www.wikidata.org port 443 (#0) * Trying 2620:0:861:ed1a::12... * connected [...cut...] * SSLv3, TLS alert, Server hello (2): * SSL certificate problem: unable to get local issuer certificate * Closing connection #0",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-41,TRUE,"['The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"":\n\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n---\n\nTherefore:\n\n$ curl -v URL\n* About to connect() to www.wikidata.org port 443 (#0)\n* Trying 2620:0:861:ed1a::12...\n* connected\n[...cut...]\n* SSLv3, TLS alert, Server hello (2):\n* SSL certificate problem: unable to get local issuer certificate\n* Closing connection #0']",NA,1,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"":\n\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n---\n\nTherefore:\n\n$ curl -v URL\n* About to connect() to www.wikidata.org port 443 (#0)\n* Trying 2620:0:861:ed1a::12...\n* connected\n[...cut...]\n* SSLv3, TLS alert, Server hello (2):\n* SSL certificate problem: unable to get local issuer certificate\n* Closing connection #0",INVESTIGATION AND EXPLORATION,, 15550,Wikidata.org is using the SSL certificate for *.wikimedia.org,"* https://wikidata.org * https://www.wikidata.org * https://example.wikidata.org * https://fr.wikidata.org",1351544273,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"* https://wikidata.org * https://www.wikidata.org * https://example.wikidata.org * https://fr.wikidata.org","* URL * URL * URL * URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,['* URL\n* URL\n* URL\n* URL'],NA,1,* URL\n* URL\n* URL\n* URL,NA,, 15551,Wikidata.org is using the SSL certificate for *.wikimedia.org,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.","<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,Lang subdomains need a little further tweaking.,FUTURE PLANS,, 15551,Wikidata.org is using the SSL certificate for *.wikimedia.org,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.","<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,<^demon> Krenair: Apache config is correct.,SOLUTION DISCUSSION,, 15551,Wikidata.org is using the SSL certificate for *.wikimedia.org,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.","<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,It needs further DNS work.,FUTURE PLANS,, 15551,Wikidata.org is using the SSL certificate for *.wikimedia.org,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.","<Krenair> Ah so wikidata SSL is working now <^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. <^demon> Krenair: Apache config is correct. It needs further DNS work. And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['<Krenair> Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.,TASK PROGRESS,, 15552,Wikidata.org is using the SSL certificate for *.wikimedia.org,I've disabled auto-login to .wikidata.org until we fix SSL.,1351516871,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,I've disabled auto-login to .wikidata.org until we fix SSL.,I've disabled auto-login to .wikidata.org until we fix SSL.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[""I've disabled auto-login to .wikidata.org until we fix SSL.""]",NA,1,I've disabled auto-login to .wikidata.org until we fix SSL.,TASK PROGRESS,, 15553,Wikidata.org is using the SSL certificate for *.wikimedia.org,*** Bug 41486 has been marked as a duplicate of this bug. ***,1351515542,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,*** Bug 41486 has been marked as a duplicate of this bug. ***,*** Bug 41486 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['*** Bug 41486 has been marked as a duplicate of this bug.', '***']",NA,1,*** Bug 41486 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 15553,Wikidata.org is using the SSL certificate for *.wikimedia.org,*** Bug 41486 has been marked as a duplicate of this bug. ***,1351515542,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,*** Bug 41486 has been marked as a duplicate of this bug. ***,*** Bug 41486 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['*** Bug 41486 has been marked as a duplicate of this bug.', '***']",NA,1,***,NA,, 15554,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #3) > Knocking down to normal/normal as it's not a high priority as it's currently a > test site It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",1351409516,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #3) > Knocking down to normal/normal as it's not a high priority as it's currently a > test site It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.","(In reply to comment #3) QUOTE QUOTE It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.', 'So this should fixed asap.']",NA,1,"(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.",OBSERVED BUG BEHAVIOR,, 15554,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #3) > Knocking down to normal/normal as it's not a high priority as it's currently a > test site It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",1351409516,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #3) > Knocking down to normal/normal as it's not a high priority as it's currently a > test site It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.","(In reply to comment #3) QUOTE QUOTE It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.', 'So this should fixed asap.']",NA,1,So this should fixed asap.,MOTIVATION,, 15555,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #2) > Doesn't seem to have fixed it... Or just hasn't been deployed. It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site",1351377712,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #2) > Doesn't seem to have fixed it... Or just hasn't been deployed. It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site","(In reply to comment #2) QUOTE It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.', ""Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site""]",NA,1,(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.,SOCIAL CONVERSATION,, 15555,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #2) > Doesn't seem to have fixed it... Or just hasn't been deployed. It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site",1351377712,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #2) > Doesn't seem to have fixed it... Or just hasn't been deployed. It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site","(In reply to comment #2) QUOTE It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators Knocking down to normal/normal as it's not a high priority as it's currently a test site",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.', ""Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site""]",NA,1,"Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site",INVESTIGATION AND EXPLORATION,, 15557,Wikidata.org is using the SSL certificate for *.wikimedia.org,https://gerrit.wikimedia.org/r/#/c/30307/,1351294636,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,https://gerrit.wikimedia.org/r/#/c/30307/,URL,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,['URL'],NA,1,URL,NA,, 16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,MWHttpRequest may have to require_once() GlobalFunctions.php.,MOTIVATION,, 16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,"HTTP component set to ""redirect"", feel free to change this.",OBSERVED BUG BEHAVIOR,, 16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,--------------------------\n**Version**: 1.20.x\n**Severity**: minor,OBSERVED BUG BEHAVIOR,, 16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,"**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)",BUG REPRODUCTION,, 16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE **Description:** If * you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), * and you don't have curl (should I ?) => then you're getting failures because wfIniGetBool() is not yet defined There should be a way to require(GlobalFunctions.php) in such a case. HTTP component set to ""redirect"", feel free to change this. -------------------------- **Version**: 1.20.x **Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case.,EXPECTED BEHAVIOR,, 16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.,INVESTIGATION AND EXPLORATION,, 16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,Just tested and it happens that wfIniGetBool *is* defined at this time.,BUG REPRODUCTION ,, 16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: I need MWHttpRequest during Auth::authenticate. Just tested and it happens that wfIniGetBool *is* defined at this time. (thus I'm fine with WONTFIX) *but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.,ACTION ON ISSUE,, 16733,MWHttpRequest may have to require_once() GlobalFunctions.php,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,1321644785,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-93,TRUE,"[""You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?"", 'quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.']",NA,1,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?,SOLUTION USAGE,, 16734,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?",1321634939,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?","**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"[""**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?"", ""If so, then does it mean that such extension can't rely on MW HTTP facilities ?""]",NA,1,**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?,SOLUTION DISCUSSION,, 16734,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?",1321634939,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?","**raphael.droz** wrote: But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? If so, then does it mean that such extension can't rely on MW HTTP facilities ?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"[""**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?"", ""If so, then does it mean that such extension can't rely on MW HTTP facilities ?""]",NA,1,"If so, then does it mean that such extension can't rely on MW HTTP facilities ?",INVESTIGATION AND EXPLORATION,, 16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,Are you using MWHttpRequest::factory() directly in the extension setup code?,INVESTIGATION AND EXPLORATION,, 16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,"If so, suggest WONTFIX.",ACTION ON ISSUE,, 16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,It's expected that not everything are initialized at that time.,EXPECTED BEHAVIOR,, 16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.,INVESTIGATION AND EXPLORATION,, 16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * URL * URL * URL * URL Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.",OBSERVED BUG BEHAVIOR ,, 16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * URL * URL * URL * URL Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.",OBSERVED BUG BEHAVIOR ,, 16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * URL * URL * URL * URL Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR ,, 16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * URL * URL * URL * URL Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major.",MOTIVATION,, 16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * https://code.google.com/p/gerrit/issues/detail?id=769 * http://www.gossamer-threads.com/lists/wiki/wikitech/278195 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 * http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL fails with error: RPC failed; result=22, HTTP code = 500 Related bugs and mailing list posts: * URL * URL * URL * URL Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. Should your server's memory size be increased ? -------------------------- **Version**: unspecified **Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,Should your server's memory size be increased ?,INVESTIGATION AND EXPLORATION,, 16810,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","for info only (2012-05-19) + git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 84M + git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 184M",1337408281,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"for info only (2012-05-19) + git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 84M + git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 184M","for info only (2012-05-19) + git clone --depth 1 URL ==> 84M + git clone URL ==> 184M",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,['for info only (2012-05-19)\n+ git clone --depth 1 URL ==> 84M\n+ git clone URL ==> 184M'],NA,1,for info only (2012-05-19)\n+ git clone --depth 1 URL ==> 84M\n+ git clone URL ==> 184M,INVESTIGATION AND EXPLORATION,, 16811,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","some more examples, where shallow clones are smaller: git clone git://gitorious.org/owncloud/owncloud.git ==> 39M git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M git clone https://github.com/Pita/etherpad-lite.git ==> 4,8M git clone --depth 1 https://github.com/Pita/etherpad-lite.git ==> 2,6M",1336159366,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"some more examples, where shallow clones are smaller: git clone git://gitorious.org/owncloud/owncloud.git ==> 39M git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M git clone https://github.com/Pita/etherpad-lite.git ==> 4,8M git clone --depth 1 https://github.com/Pita/etherpad-lite.git ==> 2,6M","some more examples, where shallow clones are smaller: git clone git://gitorious.org/owncloud/owncloud.git ==> 39M git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M git clone URL ==> 4,8M git clone --depth 1 URL ==> 2,6M",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['some more examples, where shallow clones are smaller:\n\ngit clone git://gitorious.org/owncloud/owncloud.git ==> 39M\n\ngit clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M\n\n\n\ngit clone URL ==> 4,8M\n\ngit clone --depth 1 URL ==> 2,6M']",NA,1,"some more examples, where shallow clones are smaller:\n\ngit clone git://gitorious.org/owncloud/owncloud.git ==> 39M\n\ngit clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M\n\n\n\ngit clone URL ==> 4,8M\n\ngit clone --depth 1 URL ==> 2,6M",BUG REPRODUCTION,, 16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,"Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .",INVESTIGATION AND EXPLORATION,, 16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .,INVESTIGATION AND EXPLORATION,, 16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,360 MB [sic]\n\n==> Shallow clone needs 360 MB ?,INVESTIGATION AND EXPLORATION,, 16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,??,SOCIAL CONVERSATION,, 16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): git clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 178 MB git clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git du -h . ==> 360 MB [sic] ==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,I am puzzled.,SOCIAL CONVERSATION,, 16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.","Works for me with the 2.3 upgrade: $ git clone --depth 1 URL test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,"Resolving deltas: 100% (12783/12783), done.",TASK PROGRESS,, 16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.","Works for me with the 2.3 upgrade: $ git clone --depth 1 URL test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,Marking FIXED.,ACTION ON ISSSUE,, 16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: $ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.","Works for me with the 2.3 upgrade: $ git clone --depth 1 URL test-shallow-clone Cloning into 'test-shallow-clone'... remote: Counting objects: 31773, done remote: Finding sources: 100% (31773/31773) remote: Total 31773 (delta 12783), reused 16435 (delta 12783) Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. Resolving deltas: 100% (12783/12783), done. Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,"Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done.",TESTING,, 16814,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","(In reply to comment #2) > And for the record, it doesn't *crash* gerrit. It hits an exception that's > logged and it fails for the user, but it doesn't *crash* Thanks for investigating this in the logs, and for reporting!",1334344512,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"(In reply to comment #2) > And for the record, it doesn't *crash* gerrit. It hits an exception that's > logged and it fails for the user, but it doesn't *crash* Thanks for investigating this in the logs, and for reporting!","(In reply to comment #2) QUOTE QUOTE Thanks for investigating this in the logs, and for reporting!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-72,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThanks for investigating this in the logs, and for reporting!']",NA,1,"(In reply to comment #2)\nQUOTE\nQUOTE\n\nThanks for investigating this in the logs, and for reporting!",SOCIAL CONVERSATION,, 16815,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",1334344084,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"[""And for the record, it doesn't *crash* gerrit."", ""It hits an exception that's logged and it fails for the user, but it doesn't *crash*""]",NA,1,"And for the record, it doesn't *crash* gerrit.",INVESTIGATION AND EXPLORATION,, 16815,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",1334344084,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"[""And for the record, it doesn't *crash* gerrit."", ""It hits an exception that's logged and it fails for the user, but it doesn't *crash*""]",NA,1,"It hits an exception that's logged and it fails for the user, but it doesn't *crash*",INVESTIGATION AND EXPLORATION,, 16816,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.",1334343935,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"['If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).', 'We can test again then.']",NA,1,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).",FUTURE PLANS,, 16816,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.",1334343935,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). We can test again then.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"['If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).', 'We can test again then.']",NA,1,We can test again then.,TESTING,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,NewUserMessage extensions breaks login.,OBSERVED BUG BEHAVIOR,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.",OBSERVED BUG BEHAVIOR,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.,OBSERVED BUG BEHAVIOR ,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Disabling the extension resolved the issue for me.,WORKAROUNDS,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Nothing showed up in the error log.,INVESTIGATION AND EXPLORATION,, 16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: Login error You have not specified a valid username. Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. -------------------------- **Version**: unspecified **Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: blocker,OBSERVED BUG BEHAVIOR,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,Sorry to go silent on this thread.,SOCIAL CONVERSATION,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.,OBSERVED BUG BEHAVIOR,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,If I deactivate it I can login.,WORKAROUNDS,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,"I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception.",BUG REPRODUCTION,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,"I'm not going to reopen this, I'll try to debug further.",CONTRIBUTION AND COMMITMENT,, 16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,I'm very confused about what is happening.,SOCIAL CONVERSATION,, 16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Unfortunately closing this report as no further information has been provided.,ACTION ON ISSUE,, 16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Thanks!,SOCIAL CONVERSATION,, 16860,NewUserMessage extensions breaks login,"**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?",1337632645,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?","**AzianAlex** wrote: Works fine for me too. Have you tried clearing your cache?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,"['**AzianAlex** wrote:\n\nWorks fine for me too.', 'Have you tried clearing your cache?']",NA,1,Have you tried clearing your cache?,INVESTIGATION AND EXPLORATION,, 16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks","**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,Can you check it once again please.,CONTRIBUTION AND COMMITMENT,, 16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks","**vivekee047** wrote: This works fine for me. Can you check it once again please. Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,Thanks,SOCIAL CONVERSATION,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Notification emails should link to https, not http.",EXPECTED BEHAVIOR,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.",OBSERVED BUG BEHAVIOR,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,See\nURL for the current\nrevision.,INVESTIGATION AND EXPLORATION,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.",OBSERVED BUG BEHAVIOR,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.,SOLUTION DISCUSSION,, 17237,"Notification emails should link to https, not http","Just got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 for all changes since your last visit. See http://en.wikipedia.org/wiki/User_talk:Multichill for the current revision. To contact the editor, visit http://en.wikipedia.org/wiki/User:Magicpiano Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you would like to switch off your notifications, visit http://en.wikipedia.org/wiki/Special:Preferences Feedback and further assistance: http://en.wikipedia.org/wiki/Help:Contents (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: Dear Multichill, The Wikipedia page ""User talk:Multichill"" has been changed on 2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking on National Register of Historic Places in Lowell, Massachusetts */ link fix See URL for all changes since your last visit. See URL for the current revision. To contact the editor, visit URL Note that additional changes to the page ""User talk:Multichill"" will not result in any further notifications, until you have logged in and visited the page. Your friendly Wikipedia notification system -- This email notification feature was enabled on English Wikipedia in May 2011 - see URL If you would like to switch off your notifications, visit URL Feedback and further assistance: URL (end) All links should be https now we properly implemented ssl. If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17238,"Notification emails should link to https, not http",Notification e-mails now use HTTPS,1404092595,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,Notification e-mails now use HTTPS,Notification e-mails now use HTTPS,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,43,TRUE,['Notification e-mails now use HTTPS'],NA,1,Notification e-mails now use HTTPS,TASK PROGRESS,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,WORKSFORME would be a valid resolution if this were attached to a general component.,ACTION ON ISSUE,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,LATER would be the valid resolution here.,ACTION ON ISSUE,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And just since you said it.,SOCIAL CONVERSATION,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,"The fact that people ""should never use http"" isn\",EXPECTED BEHAVIOR,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,", ""Even though they shouldn",SOLUTION USAGE,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,t use http doesn,NA,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,"re a minority."", ",NA,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,Since it's already possible to configure $wgCanonicalServer to put https links into the emails.,WORKAROUNDS,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things.,SOLUTION USAGE,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And naturally this isn't a bug tracking when https will be fully deployed.,ISSUE CONTENT MANAGEMENT,, 17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. And naturally this isn't a bug tracking when https will be fully deployed. And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,", 'The only people that pay attention to these kind of things are us techy people.', ",SOCIAL CONVERSATION,, 17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,How many logged in users are now use http and how many users https?,INVESTIGATION AND EXPLORATION,, 17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,In this day in age logged in users should never use http.,EXPECTED BEHAVIOR,, 17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,Added this one to the tracker,ACTION ON ISSUE,, 17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,You can't just close this as worksforme because it doesn't work.,ACTION ON ISSUE,, 17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker","You can't just close this as worksforme because it doesn't work. Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,Where do you base your assumption on that the SSL cluster can't handle the load?,INVESTIGATION AND EXPLORATION,, 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.",ACTION ON ISSUE,, 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"Note that to enable https by default, all we need to do is set wgCanonicalServer to https.",SOLUTION DISCUSSION,, 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.,SOLUTION DISCUSSION,, 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,There is a bug open about that already.,ISSUE CONTENT MANAGEMENT,, 17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: * (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) * (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"That's just a configuration change, no software change.",SOLUTION DISCUSSION,, 17242,"Notification emails should link to https, not http","I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.",1326146714,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.","I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-86,TRUE,"['I say fix this one.', ""It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.""]",NA,1,I say fix this one.,CONTRIBUTION AND COMMITMENT,, 17242,"Notification emails should link to https, not http","I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.",1326146714,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.","I say fix this one. It's a pretty easy fix ;-) You should leave #29878 open as a MediaWiki enhancement.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-86,TRUE,"['I say fix this one.', ""It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.""]",NA,1,It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.,ISSUE CONTENT MANAGEMENT,, 17243,"Notification emails should link to https, not http","(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) QUOTE QUOTE The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,"(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.",SOLUTION DISCUSSION,, 17243,"Notification emails should link to https, not http","(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) QUOTE QUOTE The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,I do prefer this solution.,SOLUTION DISCUSSION,, 17243,"Notification emails should link to https, not http","(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) > This is not a duplicate. #29878 is about user preferences. This bug is about > setting everything to https by default (instead of the current http). The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) QUOTE QUOTE The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,We'll have to choose one.,SOLUTION DISCUSSION,, 17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,This is not a duplicate.,ISSUE CONTENT MANAGEMENT,, 17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,#29878 is about user preferences.,ISSUE CONTENT MANAGEMENT,, 17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,This bug is about setting everything to https by default (instead of the current http).,INVESTIGATION AND EXPLORATION,, 17245,"Notification emails should link to https, not http"," %%%*** This bug has been marked as a duplicate of bug 29878 ***%%%",1322838348,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment," %%%*** This bug has been marked as a duplicate of bug 29878 ***%%%"," %%%*** This bug has been marked as a duplicate of bug 29878 ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-91,TRUE,['\n\n%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%'],NA,1,\n\n%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%,ACTION ON ISSUE,, 17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL URL Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.,OBSERVED BUG BEHAVIOR,, 17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL URL Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,For URL\n\nURL\n\nSome sort of Guru meditation.,OBSERVED BUG BEHAVIOR,, 17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL URL Some sort of Guru meditation. -------------------------- **Version**: wmf-deployment **Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: wmf-deployment\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17530,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"This is same as T200313, closing as duplicate.",1569621031,PHID-USER-j7jwnj5chzo76nqqvgqc,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"This is same as T200313, closing as duplicate.","This is same as T200313, closing as duplicate.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,317,TRUE,"['This is same as T200313, closing as duplicate.']",NA,1,"This is same as T200313, closing as duplicate.",ACTION ON ISSUE,, 17531,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Logiz_de_la_Lune_Rousse-Affiche1900.jpg/120px-Logiz_de_la_Lune_Rousse-Affiche1900.jpg ``` Error generating thumbnail There have been too many recent failed attempts (4 or more) to render this thumbnail. Please try again later. ```",1432295639,PHID-USER-nuf2sujf7qrx4v5ixbs3,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Logiz_de_la_Lune_Rousse-Affiche1900.jpg/120px-Logiz_de_la_Lune_Rousse-Affiche1900.jpg ``` Error generating thumbnail There have been too many recent failed attempts (4 or more) to render this thumbnail. Please try again later. ```","URL ``CODE``",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,['URL\n\n``CODE``'],NA,1,URL\n\n``CODE``,NA,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Error code 137 = out of memory.,OBSERVED BUG BEHAVIOR,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,"(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.",SOCIAL CONVERSATION,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Progressive images are much more memory intensive to scale.,INVESTIGATION AND EXPLORATION,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,----\nNote: the Carbon river file is a baseline jpeg.,INVESTIGATION AND EXPLORATION,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.,ACTION ON ISSUE,, 17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) > http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ > Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg > > Some sort of Guru meditation. What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) > I determined that I'd hit bug 17645, saved the file as a baseline optimized > JPEG rather than progressive and now the thumbnails work. Sorry for the > noise. > > Perhaps the images reported in this bug are saved similarly (progressive)? Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. (In reply to Jasper Deng from comment #0) QUOTE QUOTE QUOTE QUOTE What's the use case for generating a 6000px wide thumbnail? (In reply to earthsound from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that would do it. Progressive images are much more memory intensive to scale. ---- Note: the Carbon river file is a baseline jpeg. Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail.,INVESTIGATION AND EXPLORATION,, 17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) QUOTE Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.,SOCIAL CONVERSATION,, 17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) QUOTE Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,"We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.",TESTING ,, 17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) QUOTE Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,It\,NA,, 17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) QUOTE Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,"I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot.",SOLUTION DISCUSSION ,, 17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) > Perhaps the images reported in this bug are saved similarly (progressive)? Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) QUOTE Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,convert,NA,, 17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,Sorry for the noise.,SOCIAL CONVERSATION,, 17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,Perhaps the images reported in this bug are saved similarly (progressive)?,INVESTIGATION AND EXPLORATION,, 17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,"**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work.",WORKAROUND,, 17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: URL The preview on that page (1280px width) is broken: URL After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,"**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\",OBSERVED BUG BEHAVIOR,, 17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: URL The preview on that page (1280px width) is broken: URL After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,Error code:137,OBSERVED BUG BEHAVIOR,, 17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg The preview on that page (1280px width) is broken: https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: URL The preview on that page (1280px width) is broken: URL After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,"Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.",OBSERVED BUG BEHAVIOR,, 17536,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"I get ""Error code: 137"" nowadays.",1393621965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"I get ""Error code: 137"" nowadays.","I get ""Error code: 137"" nowadays.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['I get ""Error code: 137"" nowadays.']",NA,1,"I get ""Error code: 137"" nowadays.",OBSERVED BUG BEHAVIOR,, 17537,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #6) > I am getting a similar error when trying to download van Gogh: That's covered in bug 44071 instead.",1358500573,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #6) > I am getting a similar error when trying to download van Gogh: That's covered in bug 44071 instead.","(In reply to comment #6) QUOTE That's covered in bug 44071 instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-32,TRUE,"[""(In reply to comment #6)\nQUOTE\n\nThat's covered in bug 44071 instead.""]",NA,1,(In reply to comment #6)\nQUOTE\n\nThat's covered in bug 44071 instead.,ISSUE CONTENT MANAGEMENT,, 17538,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**DIA.Keyser** wrote: I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: http://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_De_slaapkamer_-_Google_Art_Project.jpg#file",1358449619,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**DIA.Keyser** wrote: I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: http://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_De_slaapkamer_-_Google_Art_Project.jpg#file","**DIA.Keyser** wrote: I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,['**DIA.Keyser** wrote:\n\nI am getting a similar error when trying to download any size larger than 2048px for this van Gogh:\n\nURL'],NA,1,**DIA.Keyser** wrote:\n\nI am getting a similar error when trying to download any size larger than 2048px for this van Gogh:\n\nURL,BUG REPRODUCTION,, 17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: Still reproducible at URL When I change the width: URL then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine.,WORKAROUND,, 17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: Still reproducible at http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg When I change the width: https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: Still reproducible at URL When I change the width: URL then it's fine. This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,) and bug 20312 (,NA,, 17540,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #3) > my guess is that it's failing to resize to a thumbnail that is 6565 pixels > wide. It works for smaller images. Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",1345141253,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #3) > my guess is that it's failing to resize to a thumbnail that is 6565 pixels > wide. It works for smaller images. Is it a Wikimedia or a MediaWiki issue then? (Still happening.)","(In reply to comment #3) QUOTE QUOTE Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-54,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?', '(Still happening.)']",NA,1,(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?,INVESTIGATION AND EXPLORATION,, 17540,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #3) > my guess is that it's failing to resize to a thumbnail that is 6565 pixels > wide. It works for smaller images. Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",1345141253,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #3) > my guess is that it's failing to resize to a thumbnail that is 6565 pixels > wide. It works for smaller images. Is it a Wikimedia or a MediaWiki issue then? (Still happening.)","(In reply to comment #3) QUOTE QUOTE Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-54,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?', '(Still happening.)']",NA,1,(Still happening.),SOCIAL CONVERSATION,, 17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,It works for smaller images.,TESTING ,, 17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,"fwiw, convert is failing with exit code 153.",OBSERVED BUG BEHAVIOR,, 17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide.,INVESTIGATION AND EXPLORATION,, 17542,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #1) > XID: 1391948384 This XID value seems to change on page refresh, by the way.",1335222024,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #1) > XID: 1391948384 This XID value seems to change on page refresh, by the way.","(In reply to comment #1) QUOTE This XID value seems to change on page refresh, by the way.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-71,TRUE,"['(In reply to comment #1)\nQUOTE\n\nThis XID value seems to change on page refresh, by the way.']",NA,1,"(In reply to comment #1)\nQUOTE\n\nThis XID value seems to change on page refresh, by the way.",INVESTIGATION AND EXPLORATION,, 17543,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,XID: 1391948384,1335214085,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,XID: 1391948384,XID: 1391948384,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,['XID: 1391948384'],NA,1,XID: 1391948384,NA,, 20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Default upload visibility should be ""Public (No Login Required)"".",EXPECTED BEHAVIOR,, 20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".",EXPECTED BEHAVIOR,, 20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,This is the same behavior as Bugzilla.,INVESTIGATION AND EXPLORATION,, 20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Currently, the default is ""All Users"" which requires a login.",INVESTIGATION AND EXPLORATION,, 20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",EXPECTED BEHAVIOR,, 20296,"Default upload visibility should be ""Public (No Login Required)""","This is the case now. https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states > Default View Policy: Public (No Login Required) and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.",1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"This is the case now. https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states > Default View Policy: Public (No Login Required) and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.","This is the case now. URL states QUOTE and going to URL shows ""Public"" as default.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-30,TRUE,"['This is the case now.', 'URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.']",NA,1,This is the case now.,TASK PROGRESS,, 20296,"Default upload visibility should be ""Public (No Login Required)""","This is the case now. https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states > Default View Policy: Public (No Login Required) and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.",1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"This is the case now. https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states > Default View Policy: Public (No Login Required) and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.","This is the case now. URL states QUOTE and going to URL shows ""Public"" as default.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-30,TRUE,"['This is the case now.', 'URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.']",NA,1,"URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.",TASK PROGRESS,, 20297,"Default upload visibility should be ""Public (No Login Required)""","Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies > Default View Policy: All Users After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",1417378008,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies > Default View Policy: All Users After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".","Upstream has resolved its part (creating the policy). URL now specifies QUOTE After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['Upstream has resolved its part (creating the policy).', 'URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".']",NA,1,Upstream has resolved its part (creating the policy).,TASK PROGRESS,, 20297,"Default upload visibility should be ""Public (No Login Required)""","Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies > Default View Policy: All Users After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",1417378008,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies > Default View Policy: All Users After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".","Upstream has resolved its part (creating the policy). URL now specifies QUOTE After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['Upstream has resolved its part (creating the policy).', 'URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".']",NA,1,"URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",CONTRIBUTION AND COMMITMENT,, 20298,"Default upload visibility should be ""Public (No Login Required)""",This is Low priority upstream.,1417076243,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,This is Low priority upstream.,This is Low priority upstream.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,['This is Low priority upstream.'],NA,1,This is Low priority upstream.,ISSUE CONTENT MANAGEMENT,, 20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ","QUOTE QUOTE Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). QUOTE Thanks. QUOTE QUOTE Filed as URL (""Set default permissions for file uploads to same as File application"") QUOTE Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,QUOTE\n\nThanks.,SOCIAL CONVERSATION,, 20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ","QUOTE QUOTE Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). QUOTE Thanks. QUOTE QUOTE Filed as URL (""Set default permissions for file uploads to same as File application"") QUOTE Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,"QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").",ISSUE CONTENT MANAGEMENT,, 20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ","QUOTE QUOTE Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). QUOTE Thanks. QUOTE QUOTE Filed as URL (""Set default permissions for file uploads to same as File application"") QUOTE Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files.,SOLUTION USAGE,, 20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: > /me wondering why this is set to high priority? Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). >> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. Thanks. >>! In T1248#21580, @Qgil wrote: > I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") > I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). ","QUOTE QUOTE Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). QUOTE Thanks. QUOTE QUOTE Filed as URL (""Set default permissions for file uploads to same as File application"") QUOTE Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,"However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it).",SOLUTION USAGE,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"First I wanted to check whether the files created via drag&drop are public, and they are.",INVESTIGATION AND EXPLORATION,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Then I checked the files at bugzillapreview, and they are also public.",INVESTIGATION AND EXPLORATION,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.",INVESTIGATION AND EXPLORATION,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,I could not find in phab-01 any configuration to set the default to Public.,INVESTIGATION AND EXPLORATION,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).",SOLUTION DISCUSSION,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",CONTRIBUTION AND COMMITMENT,, 20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private.",INVESTIGATION AND EXPLORATION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"First I wanted to check whether the files created via drag&drop are public, and they are.",INVESTIGATION AND EXPLORATION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Then I checked the files at bugzillapreview, and they are also public.",INVESTIGATION AND EXPLORATION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Therefore, this problems affects exclusively via URL Still a problem, but not high priority.",INVESTIGATION AND EXPLORATION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,I could not find in phab-01 any configuration to set the default to Public.,INVESTIGATION AND EXPLORATION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).",SOLUTION DISCUSSION,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",CONTRIBUTION AND COMMITMENT,, 20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. @Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private.",INVESTIGATION AND EXPLORATION,, 20302,"Default upload visibility should be ""Public (No Login Required)""","Test uploading F783 right here. {F783}",1415780409,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Test uploading F783 right here. {F783}","Test uploading F783 right here. {F783}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['Test uploading F783 right here.', '{F783}']",NA,1,Test uploading F783 right here.,TESTING ,, 20302,"Default upload visibility should be ""Public (No Login Required)""","Test uploading F783 right here. {F783}",1415780409,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Test uploading F783 right here. {F783}","Test uploading F783 right here. {F783}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['Test uploading F783 right here.', '{F783}']",NA,1,{F783},NA,, 20303,"Default upload visibility should be ""Public (No Login Required)""","/me wondering why this is set to high priority? > (or changing visibility of an existing file to non-public) For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: > Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.",1415755584,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"/me wondering why this is set to high priority? > (or changing visibility of an existing file to non-public) For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: > Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.","/me wondering why this is set to high priority? QUOTE For the records, URL states: QUOTE",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['/me wondering why this is set to high priority?', 'QUOTE\n\nFor the records, URL states:\nQUOTE']",NA,1,/me wondering why this is set to high priority?,ISSUE CONTENT MANAGEMENT,, 20303,"Default upload visibility should be ""Public (No Login Required)""","/me wondering why this is set to high priority? > (or changing visibility of an existing file to non-public) For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: > Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.",1415755584,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"/me wondering why this is set to high priority? > (or changing visibility of an existing file to non-public) For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: > Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.","/me wondering why this is set to high priority? QUOTE For the records, URL states: QUOTE",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['/me wondering why this is set to high priority?', 'QUOTE\n\nFor the records, URL states:\nQUOTE']",NA,1,"QUOTE\n\nFor the records, URL states:\nQUOTE",SOCIAL CONVERSATION,, 21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,Fix cert handling in our ldap servers.,OBSERVED BUG BEHAVIOR,, 21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,We just had an ldap outage because the ldap cert setup is... unexpected.,OBSERVED BUG BEHAVIOR,, 21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?,INVESTIGATION AND EXPLORATION,, 21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. [4:55pm] paravoid: this is pretty broken in general [4:55pm] Coren: paravoid: What was the issue? [4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA [4:55pm] paravoid: which is pretty broken [4:55pm] paravoid: that's a single intermediate CA, not a certificate store [4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root [4:56pm] paravoid: also quite broken ... paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,"[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",INVESTIGATION AND EXPLORATION,, 21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,This is fixed in puppet with rOPUP1a195544eaed.,TASK PROGRESS,, 21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,CODE seems to verify that the full chain is being served now.,TASK PROGRESS,, 21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,"The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus.",CONTRIBUTION AND COMMITMENT,, 21121,Fix cert handling in our ldap servers,"Change 215808 merged by Faidon Liambotis: ldap: serve the full certificate chain for TLS [[https://gerrit.wikimedia.org/r/215808]]",1433371991,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"Change 215808 merged by Faidon Liambotis: ldap: serve the full certificate chain for TLS [[https://gerrit.wikimedia.org/r/215808]]","Change 215808 merged by Faidon Liambotis: ldap: serve the full certificate chain for TLS [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,['Change 215808 merged by Faidon Liambotis:\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]]'],NA,1,Change 215808 merged by Faidon Liambotis:\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]],TASK PROGRESS,, 21122,Fix cert handling in our ldap servers,"Change 215808 had a related patch set uploaded (by Faidon Liambotis): ldap: serve the full certificate chain for TLS [[https://gerrit.wikimedia.org/r/215808]] ",1433371918,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"Change 215808 had a related patch set uploaded (by Faidon Liambotis): ldap: serve the full certificate chain for TLS [[https://gerrit.wikimedia.org/r/215808]] ","Change 215808 had a related patch set uploaded (by Faidon Liambotis): ldap: serve the full certificate chain for TLS [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,['Change 215808 had a related patch set uploaded (by Faidon Liambotis):\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]]'],NA,1,Change 215808 had a related patch set uploaded (by Faidon Liambotis):\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]],TASK PROGRESS,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,openssl 1.0.2 packaging for jessie.,EXPECTED BEHAVIOR,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.,SOLUTION DISCUSSION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.,SOLUTION DISCUSSION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",SOLUTION DISCUSSION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN.",SOLUTION DISCUSSION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment.",SOLUTION DISCUSSION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]].",POTENTIAL NEW ISSUES AND REQUESTS,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has.",INVESTIGATION AND EXPLORATION,, 22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue.",INVESTIGATION AND EXPLORATION,, 22433,openssl 1.0.2 packaging for jessie,">>! In T104143#1877286, @Remware wrote: > My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point... jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767661",1450092543,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,">>! In T104143#1877286, @Remware wrote: > My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point... jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767661","QUOTE QUOTE jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"['QUOTE\nQUOTE\n\njessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL']",NA,1,"QUOTE\nQUOTE\n\njessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL",SOLUTION USAGE,, 22434,openssl 1.0.2 packaging for jessie,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",1450092286,PHID-USER-3rlfi3mnvi7zx76ucrz2,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...","My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,23,TRUE,"['My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...']",NA,1,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",CONTRIBUTION AND COMMITMENT ,, 22435,openssl 1.0.2 packaging for jessie,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",1450092042,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.","I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g."", 'nginx) against it as well.']",NA,1,nginx) against it as well.,NA,, 22435,openssl 1.0.2 packaging for jessie,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",1450092042,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.","I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g."", 'nginx) against it as well.']",NA,1,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g.",INVESTIGATION AND EXPLORATION,, 22436,openssl 1.0.2 packaging for jessie,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",1450091917,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.","SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no."", 'The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.']",NA,1,"The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",SOLUTION DISCUSSION ,, 22436,openssl 1.0.2 packaging for jessie,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",1450091917,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.","SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no."", 'The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.']",NA,1,"SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no.",SOLUTION DISCUSSION,, 22437,openssl 1.0.2 packaging for jessie,Do we have jessie package already in stable ?,1450091718,PHID-USER-3rlfi3mnvi7zx76ucrz2,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,Do we have jessie package already in stable ?,Do we have jessie package already in stable ?,NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,23,TRUE,['Do we have jessie package already in stable ?'],NA,1,Do we have jessie package already in stable ?,INVESTIGATION AND EXPLORATION,, 22438,openssl 1.0.2 packaging for jessie,">>! In T104143#1411211, @BBlack wrote: > (or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?) That would work as well; the udebs are only needed for d-i.",1435605939,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,">>! In T104143#1411211, @BBlack wrote: > (or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?) That would work as well; the udebs are only needed for d-i.","QUOTE QUOTE That would work as well; the udebs are only needed for d-i.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,['QUOTE\nQUOTE\n\nThat would work as well; the udebs are only needed for d-i.'],NA,1,QUOTE\nQUOTE\n\nThat would work as well; the udebs are only needed for d-i.,SOLUTION DISCUSSION,, 22439,openssl 1.0.2 packaging for jessie,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",1435605409,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)","(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)""]",NA,1,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",SOLUTION DISCUSSION,, 22440,openssl 1.0.2 packaging for jessie,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",1435605399,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?","(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?""]",NA,1,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",SOLUTION DISCUSSION,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,That makes this a trivial backport as well.,SOLUTION DISCUSSION,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"Per IRC discussion, I\",NA,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.",INVESTIGATION AND EXPLORATION,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine.",CONTRIBUTION AND COMMITMENT,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,upstream,NA,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,master,NA,, 22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``` root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes .changes put in a distribution not listed within it! Ignoring as --ignore=wrongdistribution given. Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! ``` This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? ``` Origin: Wikimedia Label: Wikimedia Suite: jessie-wikimedia Codename: jessie-wikimedia AlsoAcceptFor: jessie jessie-backports Version: 8 Architectures: source amd64 i386 Components: main backports thirdparty UDebComponents: main Update: hwraid cassandra Description: Wikimedia packages for Debian Jessie SignWith: default DebOverride: deb-override Log: log ``` But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: ``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...",OBSERVED BUG BEHAVIOR,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).,INVESTIGATION AND EXPLORATION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I think we should update our openssl build by following their point releases.,SOLUTION DISCUSSION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.",SOLUTION DISCUSSION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation.,SOLUTION DISCUSSION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'd rather wait until it has seen some upstream scrutiny.,CONTRIBUTION AND COMMITMENT,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there.,SOLUTION DISCUSSION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now).",INVESTIGATION AND EXPLORATION,, 22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL",INVESTIGATION AND EXPLORATION ,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).,INVESTIGATION AND EXPLORATION ,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I think we should update our openssl build by following their point releases.,SOLUTION DISCUSSION ,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.",SOLUTION DISCUSSION ,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation.,SOLUTION DISCUSSION,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'd rather wait until it has seen some upstream scrutiny.,CONTRIBUTION AND COMMITMENT ,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there.,SOLUTION DISCUSSION,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now).",INVESTIGATION AND EXPLORATION,, 22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL",INVESTIGATION AND EXPLORATION,, 23461,Occasionally getting 403 HTTP Method not allowed from bits,For example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,1426632739,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-nr2rykz2i64vicqql4ad,task_description,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET URL,Needs Triage,90,1430784755,PHID-USER-orzyp3dswemhdgdznro5,duplicate,TRUE,c3,1,TRUE,FALSE,-16,TRUE,"['Occasionally getting 403 HTTP Method not allowed from bits.', 'For example I just received this error while trying to GET URL']",TRUE,1,Occasionally getting 403 HTTP Method not allowed from bits.,OBSERVED BUG BEHAVIOR,, 23461,Occasionally getting 403 HTTP Method not allowed from bits,For example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,1426632739,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-nr2rykz2i64vicqql4ad,task_description,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET URL,Needs Triage,90,1430784755,PHID-USER-orzyp3dswemhdgdznro5,duplicate,TRUE,c3,1,TRUE,FALSE,-16,TRUE,"['Occasionally getting 403 HTTP Method not allowed from bits.', 'For example I just received this error while trying to GET URL']",TRUE,1,For example I just received this error while trying to GET URL,OBSERVED BUG BEHAVIOR,, 23462,Occasionally getting 403 HTTP Method not allowed from bits,See T98046 for a more documented bug report :),1430784783,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,See T98046 for a more documented bug report :),See T98046 for a more documented bug report :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-9,TRUE,['See T98046 for a more documented bug report :)'],NA,1,See T98046 for a more documented bug report :),ISSUE CONTENT MANAGEMENT,, 23463,Occasionally getting 403 HTTP Method not allowed from bits,Works for me.,1430763846,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,Works for me.,Works for me.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-9,TRUE,['Works for me.'],NA,1,Works for me.,SOCIAL CONVERSATION,, 23464,Occasionally getting 403 HTTP Method not allowed from bits,Still an issue?,1429295849,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,Still an issue?,Still an issue?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-11,TRUE,['Still an issue?'],NA,1,Still an issue?,SOCIAL CONVERSATION,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).",EXPECTED BEHAVIOR,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"Thus, writing it to ""the exception log"" with wfDebugLog( \",NA,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,", ... ) is misleading.",NA,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.,EXPECTED BEHAVIOR,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.",EXPECTED BEHAVIOR,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"""http-error"" instead of the generic ""exception"" log.",SOLUTION DISCUSSION,, 23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. I suggest the following behavior: * HttpError::isLoggable should return false if $this->httpCode < 500. * HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",SOLUTION DISCUSSION,, 23680,HttpError should not be logged as an unhandled exception.,"Change 183020 merged by jenkins-bot: Don't log HttpErrors in the exception log, use MWLogger [[https://gerrit.wikimedia.org/r/183020]]",1426694449,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 183020 merged by jenkins-bot: Don't log HttpErrors in the exception log, use MWLogger [[https://gerrit.wikimedia.org/r/183020]]","Change 183020 merged by jenkins-bot: Don't log HttpErrors in the exception log, use MWLogger [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,"[""Change 183020 merged by jenkins-bot:\nDon't log HttpErrors in the exception log, use MWLogger\n\n[[GERRIT_URL]]""]",NA,1,"Change 183020 merged by jenkins-bot:\nDon't log HttpErrors in the exception log, use MWLogger\n\n[[GERRIT_URL]]",TASK PROGRESS,, 23681,HttpError should not be logged as an unhandled exception.,"Change 197503 merged by Legoktm: Log HttpErrors with a 500 code [[https://gerrit.wikimedia.org/r/197503]]",1426693431,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 197503 merged by Legoktm: Log HttpErrors with a 500 code [[https://gerrit.wikimedia.org/r/197503]]","Change 197503 merged by Legoktm: Log HttpErrors with a 500 code [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,['Change 197503 merged by Legoktm:\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]]'],NA,1,Change 197503 merged by Legoktm:\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]],TASK PROGRESS,, 23682,HttpError should not be logged as an unhandled exception.,"Change 197503 had a related patch set uploaded (by Hoo man): Log HttpErrors with a 500 code [[https://gerrit.wikimedia.org/r/197503]] ",1426674262,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 197503 had a related patch set uploaded (by Hoo man): Log HttpErrors with a 500 code [[https://gerrit.wikimedia.org/r/197503]] ","Change 197503 had a related patch set uploaded (by Hoo man): Log HttpErrors with a 500 code [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,['Change 197503 had a related patch set uploaded (by Hoo man):\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]]'],NA,1,Change 197503 had a related patch set uploaded (by Hoo man):\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]],TASK PROGRESS,, 23683,HttpError should not be logged as an unhandled exception.,">>! In T85795#960163, @Legoktm wrote: >>>! In T85795#960109, @JanZerebecki wrote: >> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. > > Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",1420658816,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960163, @Legoktm wrote: >>>! In T85795#960109, @JanZerebecki wrote: >> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. > > Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.","QUOTE QUOTE QUOTE QUOTE QUOTE The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.', '\\o/ No config updates have been done to use it yet.']",NA,1,QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.,TASK PROGRESS,, 23683,HttpError should not be logged as an unhandled exception.,">>! In T85795#960163, @Legoktm wrote: >>>! In T85795#960109, @JanZerebecki wrote: >> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. > > Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",1420658816,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960163, @Legoktm wrote: >>>! In T85795#960109, @JanZerebecki wrote: >> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. > > Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.","QUOTE QUOTE QUOTE QUOTE QUOTE The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.', '\\o/ No config updates have been done to use it yet.']",NA,1,\\o/ No config updates have been done to use it yet.,SOLUTION DISCUSSION,, 23684,HttpError should not be logged as an unhandled exception.,">>! In T85795#960109, @JanZerebecki wrote: > The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ",1420654141,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960109, @JanZerebecki wrote: > The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ","QUOTE QUOTE Actually, we now have structured logging in MW: CODE will return an instance of CODE that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.', 'You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).']",NA,1,"QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.",TASK PROGRESS,, 23684,HttpError should not be logged as an unhandled exception.,">>! In T85795#960109, @JanZerebecki wrote: > The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ",1420654141,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960109, @JanZerebecki wrote: > The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ","QUOTE QUOTE Actually, we now have structured logging in MW: CODE will return an instance of CODE that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.', 'You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).']",NA,1,You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).,SOLUTION USAGE,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,The goal is that everything that is logged can be easily differentiated according to its severity.,MOTIVATION,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.,MOTIVATION,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,A 404 of this case is the later case.,SOLUTION DISCUSSION ,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,AFAIK in Mediawiki the log group is the only thing that can be currently used for this.,INVESTIGATION AND EXPLORATION,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,To have isLoggable() return false but then have the exception log itself inside report() is more of a workaround for the lack of being able to specify the log group.,WORKAROUNDS,, 23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?,SOLUTION DISCUSSION,, 23686,HttpError should not be logged as an unhandled exception.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,1420565761,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['Thx.', ""No wonder searching for type in that file didn't find where it was set to HttpError.""]",NA,1,Thx.,SOCIAL CONVERSATION,, 23686,HttpError should not be logged as an unhandled exception.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,1420565761,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['Thx.', ""No wonder searching for type in that file didn't find where it was set to HttpError.""]",NA,1,No wonder searching for type in that file didn't find where it was set to HttpError.,SOCIAL CONVERSATION,, 23687,HttpError should not be logged as an unhandled exception.,">>! In T85795#957697, @JanZerebecki wrote: > I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? It happens from the exception-json event processing. See <https://github.com/wikimedia/operations-puppet/blob/production/files/logstash/filter-mw-via-udp2log.conf#L279-L301>",1420565282,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#957697, @JanZerebecki wrote: > I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? It happens from the exception-json event processing. See <https://github.com/wikimedia/operations-puppet/blob/production/files/logstash/filter-mw-via-udp2log.conf#L279-L301>","QUOTE QUOTE It happens from the exception-json event processing. See <URL",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nIt happens from the exception-json event processing.', 'See <URL']",NA,1,QUOTE\nQUOTE\n\nIt happens from the exception-json event processing.,INVESTIGATION AND EXPLORATION ,, 23687,HttpError should not be logged as an unhandled exception.,">>! In T85795#957697, @JanZerebecki wrote: > I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? It happens from the exception-json event processing. See <https://github.com/wikimedia/operations-puppet/blob/production/files/logstash/filter-mw-via-udp2log.conf#L279-L301>",1420565282,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#957697, @JanZerebecki wrote: > I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? It happens from the exception-json event processing. See <https://github.com/wikimedia/operations-puppet/blob/production/files/logstash/filter-mw-via-udp2log.conf#L279-L301>","QUOTE QUOTE It happens from the exception-json event processing. See <URL",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nIt happens from the exception-json event processing.', 'See <URL']",NA,1,See <URL,NA,, 23688,HttpError should not be logged as an unhandled exception.,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,1420564891,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"[""I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception."", 'Any ideas?']",NA,1,Any ideas?,SOCIAL CONVERSATION ,, 23688,HttpError should not be logged as an unhandled exception.,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,1420564891,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"[""I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception."", 'Any ideas?']",NA,1,I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception.,INVESTIGATION AND EXPLORATION,, 23689,HttpError should not be logged as an unhandled exception.,"Change 183020 had a related patch set uploaded (by Hoo man): Don't log HttpErrors in the exception log [[https://gerrit.wikimedia.org/r/183020]] #patch-for-review",1420544378,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 183020 had a related patch set uploaded (by Hoo man): Don't log HttpErrors in the exception log [[https://gerrit.wikimedia.org/r/183020]] #patch-for-review","Change 183020 had a related patch set uploaded (by Hoo man): Don't log HttpErrors in the exception log [[GERRIT_URL]] #patch-for-review",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-26,TRUE,"[""Change 183020 had a related patch set uploaded (by Hoo man):\nDon't log HttpErrors in the exception log\n\n[[GERRIT_URL]]\n\n#patch-for-review""]",NA,1,Change 183020 had a related patch set uploaded (by Hoo man):\nDon't log HttpErrors in the exception log\n\n[[GERRIT_URL]]\n\n#patch-for-review,TASK PROGRESS,, 23690,HttpError should not be logged as an unhandled exception.,This came up during https://gerrit.wikimedia.org/r/#/c/182750/ T76458.,1420473861,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,This came up during https://gerrit.wikimedia.org/r/#/c/182750/ T76458.,This came up during URL T76458.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,['This came up during URL T76458.'],NA,1,This came up during URL T76458.,ISSUE CONTENT MANAGEMENT,, 23691,HttpError should not be logged as an unhandled exception.,"Often 404 errors where this is used are of no interest to ops or devs, so I prefer the different log stream, at least for 404.",1420473820,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Often 404 errors where this is used are of no interest to ops or devs, so I prefer the different log stream, at least for 404.","Often 404 errors where this is used are of no interest to ops or devs, so I prefer the different log stream, at least for 404.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['Often 404 errors where this is used are of no interest to ops or devs, so I prefer the different log stream, at least for 404.']",NA,1,"Often 404 errors where this is used are of no interest to ops or devs, so I prefer the different log stream, at least for 404.",SOLUTION USAGE,, 23725,Generic login failed message when password is wrong,"The app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ",1430257660,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_description,"Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ","Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See URL According toSCREEN_NAME we should treat both error codes as the same. ",High,80,1434132708,PHID-USER-5gog4v3xjj6mq65koqgl,resolved,TRUE,c3,1,FALSE,FALSE,-10,TRUE,"['Generic login failed message when password is wrong.', 'The app should respond with a specific error message when the user name or password is wrong while trying to log in.', 'We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".', 'See URL\nAccording toSCREEN_NAME we should treat both error codes as the same.']",TRUE,1,Generic login failed message when password is wrong.,OBSERVED BUG BEHAVIOR,, 23725,Generic login failed message when password is wrong,"The app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ",1430257660,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_description,"Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ","Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See URL According toSCREEN_NAME we should treat both error codes as the same. ",High,80,1434132708,PHID-USER-5gog4v3xjj6mq65koqgl,resolved,TRUE,c3,1,FALSE,FALSE,-10,TRUE,"['Generic login failed message when password is wrong.', 'The app should respond with a specific error message when the user name or password is wrong while trying to log in.', 'We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".', 'See URL\nAccording toSCREEN_NAME we should treat both error codes as the same.']",TRUE,1,The app should respond with a specific error message when the user name or password is wrong while trying to log in.,EXPECTED BEHAVIOR,, 23725,Generic login failed message when password is wrong,"The app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ",1430257660,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_description,"Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ","Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See URL According toSCREEN_NAME we should treat both error codes as the same. ",High,80,1434132708,PHID-USER-5gog4v3xjj6mq65koqgl,resolved,TRUE,c3,1,FALSE,FALSE,-10,TRUE,"['Generic login failed message when password is wrong.', 'The app should respond with a specific error message when the user name or password is wrong while trying to log in.', 'We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".', 'See URL\nAccording toSCREEN_NAME we should treat both error codes as the same.']",TRUE,1,"We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".",INVESTIGATION AND EXPLORATION ,, 23725,Generic login failed message when password is wrong,"The app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ",1430257660,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_description,"Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See https://www.mediawiki.org/wiki/API:Login#Errors. According to @bd808 we should treat both error codes as the same. ","Generic login failed message when password is wrong./n/nThe app should respond with a specific error message when the user name or password is wrong while trying to log in. We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"". See URL According toSCREEN_NAME we should treat both error codes as the same. ",High,80,1434132708,PHID-USER-5gog4v3xjj6mq65koqgl,resolved,TRUE,c3,1,FALSE,FALSE,-10,TRUE,"['Generic login failed message when password is wrong.', 'The app should respond with a specific error message when the user name or password is wrong while trying to log in.', 'We currently try to detect that by checking the API response for ""WrongPass"" but not for ""WrongPluginPass"".', 'See URL\nAccording toSCREEN_NAME we should treat both error codes as the same.']",TRUE,1,See URL\nAccording toSCREEN_NAME we should treat both error codes as the same.,EXPECTED BEHAVIOR,, 23726,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717065,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the copy, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,The red banner seems to be covering the input field.,OBSERVED BUG BEHAVIOR,, 23726,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717065,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the copy, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,Principally input fields must not be obfuscated for messaging.,EXPECTED BEHAVIOR,, 23726,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717065,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the copy, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,I might have to file a separate ticket for error message display concerns.,ISSUE CONTENT MANAGEMENT,, 23726,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717065,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the copy, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,Signed off by design.,TASK PROGRESS,, 23726,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717065,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the copy, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the copy, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,"Since this task is simply about the copy, i'm ok with signing off on it.",ACTION ON ISSUE,, 23727,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717045,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the error messaging, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,The red banner seems to be covering the input field.,OBSERVED BUG BEHAVIOR,, 23727,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717045,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the error messaging, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,Principally input fields must not be obfuscated for messaging.,EXPECTED BEHAVIOR,, 23727,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717045,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the error messaging, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,I might have to file a separate ticket for error message display concerns.,ISSUE CONTENT MANAGEMENT,, 23727,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717045,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the error messaging, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,Signed off by design.,TASK PROGRESS,, 23727,Generic login failed message when password is wrong,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",1431717045,PHID-USER-rooknayvbydy6sodz3lx,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ","The red banner seems to be covering the input field. Principally input fields must not be obfuscated for messaging. Since this task is simply about the error messaging, i'm ok with signing off on it. I might have to file a separate ticket for error message display concerns. Signed off by design. ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-7,TRUE,"['The red banner seems to be covering the input field.', 'Principally input fields must not be obfuscated for messaging.', ""Since this task is simply about the error messaging, i'm ok with signing off on it."", 'I might have to file a separate ticket for error message display concerns.', 'Signed off by design.']",NA,1,"Since this task is simply about the error messaging, i'm ok with signing off on it.",ACTION ON ISSUE,, 23728,Generic login failed message when password is wrong,"|case| username |password|Message| |1|correct |correct| Login success!| |2| incorrect| correct|Incorrect username| |3| correct|incorrect|Incorrect password| |4|incorrect|incorrect|Login failed:(| {F159473} ",1430520582,PHID-USER-4alekd35in5tg53zpsl4,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"|case| username |password|Message| |1|correct |correct| Login success!| |2| incorrect| correct|Incorrect username| |3| correct|incorrect|Incorrect password| |4|incorrect|incorrect|Login failed:(| {F159473} ","|case| username |password|Message| |1|correct |correct| Login success!| |2| incorrect| correct|Incorrect username| |3| correct|incorrect|Incorrect password| |4|incorrect|incorrect|Login failed:(| {F159473} ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-9,TRUE,['|case| username |password|Message|\n|1|correct |correct| Login success!|\n|2| incorrect| correct|Incorrect username|\n|3| correct|incorrect|Incorrect password|\n|4|incorrect|incorrect|Login failed:(|\n\n{F159473}'],NA,1,|case| username |password|Message|\n|1|correct |correct| Login success!|\n|2| incorrect| correct|Incorrect username|\n|3| correct|incorrect|Incorrect password|\n|4|incorrect|incorrect|Login failed:(|\n\n{F159473},NA,, 23729,Generic login failed message when password is wrong,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",1430260749,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).","QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"[""QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g."", 'add a space or slash in the user field).', 'The difference for the WrongPluginPass vs. WrongPass is how auth is happening.', 'The WrongPluginPass code is used when CentralAuth is involved (e.g.', 'the account is not a local account).']",NA,1,add a space or slash in the user field).,SOLUTION DISCUSSION,, 23729,Generic login failed message when password is wrong,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",1430260749,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).","QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"[""QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g."", 'add a space or slash in the user field).', 'The difference for the WrongPluginPass vs. WrongPass is how auth is happening.', 'The WrongPluginPass code is used when CentralAuth is involved (e.g.', 'the account is not a local account).']",NA,1,The difference for the WrongPluginPass vs. WrongPass is how auth is happening.,INVESTIGATION AND EXPLORATION,, 23729,Generic login failed message when password is wrong,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",1430260749,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).","QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"[""QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g."", 'add a space or slash in the user field).', 'The difference for the WrongPluginPass vs. WrongPass is how auth is happening.', 'The WrongPluginPass code is used when CentralAuth is involved (e.g.', 'the account is not a local account).']",NA,1,The WrongPluginPass code is used when CentralAuth is involved (e.g.,INVESTIGATION AND EXPLORATION,, 23729,Generic login failed message when password is wrong,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",1430260749,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).","QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"[""QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g."", 'add a space or slash in the user field).', 'The difference for the WrongPluginPass vs. WrongPass is how auth is happening.', 'The WrongPluginPass code is used when CentralAuth is involved (e.g.', 'the account is not a local account).']",NA,1,the account is not a local account).,NA,, 23729,Generic login failed message when password is wrong,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",1430260749,PHID-USER-tjyfydvd4ncrfvvr6mkr,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"QA: BTW, @Deskana's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).","QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g. add a space or slash in the user field). The difference for the WrongPluginPass vs. WrongPass is how auth is happening. The WrongPluginPass code is used when CentralAuth is involved (e.g. the account is not a local account).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"[""QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g."", 'add a space or slash in the user field).', 'The difference for the WrongPluginPass vs. WrongPass is how auth is happening.', 'The WrongPluginPass code is used when CentralAuth is involved (e.g.', 'the account is not a local account).']",NA,1,"QA: BTW,SCREEN_NAME's patch also handles illegal characters in usernames (e.g.",SOLUTION DISCUSSION,, 23730,Generic login failed message when password is wrong,"Change 207287 merged by jenkins-bot: Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]]",1430260528,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"Change 207287 merged by jenkins-bot: Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]]","Change 207287 merged by jenkins-bot: Handle some more login API errors. [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"['Change 207287 merged by jenkins-bot:\nHandle some more login API errors.', '[[GERRIT_URL]]']",NA,1,Change 207287 merged by jenkins-bot:\nHandle some more login API errors.,TASK PROGRESS,, 23730,Generic login failed message when password is wrong,"Change 207287 merged by jenkins-bot: Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]]",1430260528,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"Change 207287 merged by jenkins-bot: Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]]","Change 207287 merged by jenkins-bot: Handle some more login API errors. [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"['Change 207287 merged by jenkins-bot:\nHandle some more login API errors.', '[[GERRIT_URL]]']",NA,1,[[GERRIT_URL]],NA,, 23731,Generic login failed message when password is wrong,"Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]] ",1430258912,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]] ","Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"['Change 207287 had a related patch set uploaded (by Deskana):\nHandle some more login API errors.', '[[GERRIT_URL]]']",NA,1,Change 207287 had a related patch set uploaded (by Deskana):\nHandle some more login API errors.,TASK PROGRESS,, 23731,Generic login failed message when password is wrong,"Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]] ",1430258912,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,"Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[https://gerrit.wikimedia.org/r/207287]] ","Change 207287 had a related patch set uploaded (by Deskana): Handle some more login API errors. [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-10,TRUE,"['Change 207287 had a related patch set uploaded (by Deskana):\nHandle some more login API errors.', '[[GERRIT_URL]]']",NA,1,[[GERRIT_URL]],NA,, 23732,Generic login failed message when password is wrong,@bearND Sorry for snagging this from you without realising you were working on it. :-(,1430258486,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,@bearND Sorry for snagging this from you without realising you were working on it. :-(,SCREEN_NAME Sorry for snagging this from you without realising you were working on it. :-(,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['SCREEN_NAME Sorry for snagging this from you without realising you were working on it.', ':-(']",NA,1,SCREEN_NAME Sorry for snagging this from you without realising you were working on it.,CONTRIBUTION AND COMMITMENT,, 23732,Generic login failed message when password is wrong,@bearND Sorry for snagging this from you without realising you were working on it. :-(,1430258486,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,@bearND Sorry for snagging this from you without realising you were working on it. :-(,SCREEN_NAME Sorry for snagging this from you without realising you were working on it. :-(,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['SCREEN_NAME Sorry for snagging this from you without realising you were working on it.', ':-(']",NA,1,:-(,SOCIAL CONVERSATION,, 23733,Generic login failed message when password is wrong,This patch should address this: https://gerrit.wikimedia.org/r/#/c/207287/,1430258132,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-f4xnx6uzc3brnlmedskh,task_subcomment,This patch should address this: https://gerrit.wikimedia.org/r/#/c/207287/,This patch should address this: URL,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,['This patch should address this: URL'],NA,1,This patch should address this: URL,SOLUTION DISCUSSION,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,HTTPS performance & UA adoption metrics.,EXPECTED BEHAVIOR,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,We should get more insight there.,SOCIAL CONVERSATION,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,Probably blocked on T86648.,ISSUE CONTENT MANAGEMENT,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2.",MOTIVATION,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards).,MOTIVATION,, 24692,HTTPS performance & UA adoption metrics,"We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",1421160279,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_description,"HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.","HTTPS performance & UA adoption metrics./n/nWe're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2. We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards). We should get more insight there. I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it. Probably blocked on T86648.",Medium,50,1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,1,TRUE,FALSE,-25,TRUE,"['HTTPS performance & UA adoption metrics.', ""We're currently flying mostly blind as far HTTPS metrics go; we don't know, for example, what percentage of users supports which versions of TLS or ciphers, or (soon) SPDY/HTTP2."", ""We do have some NavTiming metrics but we don't have a great way of displaying these (dashboards)."", 'We should get more insight there.', ""I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it."", 'Probably blocked on T86648.']",TRUE,1,I've previously experimented with nginx lua + statsd plugin that logged ciphers & protocols and it did work fine but we should think of it more eloquently and deploy it.,EXPECTED BEHAVIOR,, 24693,HTTPS performance & UA adoption metrics,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.","We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,5,TRUE,"[""We're not exactly flying blind anymore."", 'Analytics has done a bunch of independent analysis post-switch.', ""We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else."", 'Considering this done.']",NA,1,Analytics has done a bunch of independent analysis post-switch.,TASK PROGRESS,, 24693,HTTPS performance & UA adoption metrics,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.","We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,5,TRUE,"[""We're not exactly flying blind anymore."", 'Analytics has done a bunch of independent analysis post-switch.', ""We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else."", 'Considering this done.']",NA,1,Considering this done.,ACTION ON ISSUE,, 24693,HTTPS performance & UA adoption metrics,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.","We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,5,TRUE,"[""We're not exactly flying blind anymore."", 'Analytics has done a bunch of independent analysis post-switch.', ""We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else."", 'Considering this done.']",NA,1,We're not exactly flying blind anymore.,TASK PROGRESS,, 24693,HTTPS performance & UA adoption metrics,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",1438966759,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.","We're not exactly flying blind anymore. Analytics has done a bunch of independent analysis post-switch. We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else. Considering this done.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,5,TRUE,"[""We're not exactly flying blind anymore."", 'Analytics has done a bunch of independent analysis post-switch.', ""We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else."", 'Considering this done.']",NA,1,"We've got cipher/protocol/sessionid metrics going to graphite and tessera, and of course since we're past the switch date we can already see the raw perf impact everywhere else.",TASK PROGRESS,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Thanks for creating this task.,SOCIAL CONVERSATION,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.,ISSUE CONTENT MANAGEMENT,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Just titles would suffice.,SOLUTION DISCUSSION,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,"With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.",CONTRIBUTION AND COMMITMENT ,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,":)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?",SOLUTION DISCUSSION,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,"(Some unlikely, e.g.",SOCIAL CONVERSATION,, 24694,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201566,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nicer if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,bounce rate.),NA,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Thanks for creating this task.,SOCIAL CONVERSATION,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.,ISSUE CONTENT MANAGEMENT,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Just titles would suffice.,SOLUTION DISCUSSION,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,"With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.",CONTRIBUTION AND COMMITMENT ,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,":)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?",SOLUTION DISCUSSION,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,"(Some unlikely, e.g.",SOCIAL CONVERSATION,, 24695,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201510,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', 'With its current definition the task is too vague, it may range from few hours of work to add some graph for existing data to years of work for entire university departments.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,bounce rate.),NA,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Thanks for creating this task.,SOCIAL CONVERSATION,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.,ISSUE CONTENT MANAGEMENT,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,Just titles would suffice.,SOLUTION DISCUSSION,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,":)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?",SOLUTION DISCUSSION,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,"(Some unlikely, e.g.",SOCIAL CONVERSATION,, 24696,HTTPS performance & UA adoption metrics,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",1430201131,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-ubyrzgqhbgjg4uultdu5,task_subcomment,"Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)","Thanks for creating this task. It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned. Just titles would suffice. :) For instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...? (Some unlikely, e.g. bounce rate.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['Thanks for creating this task.', 'It would be even nice if the description mentioned *all* the research that is needed or ongoing before the big red switch for T49832 is turned.', 'Just titles would suffice.', ':)\n\nFor instance, per-country errors %, per-project errors %, per-country navtiming, per-project navtiming, editor retention, editor activation, bounce rate, number or link clicks, ...?', '(Some unlikely, e.g.', 'bounce rate.)']",NA,1,bounce rate.),NA,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,"""Edit without login"" button is hidden in editor cta.",OBSERVED BUG BEHAVIOR,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,"The button ""Edit without login"" has display:none; on the editor cta.",OBSERVED BUG BEHAVIOR,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,Steps to reproduce:\n1.,BUG REPRODUCTION,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,Go to an editable page\n3.,BUG REPRODUCTION,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,Make sure you're in alpha or anonymous editing is enabled in your configuration\n2.,BUG REPRODUCTION,, 24990,"""Edit without login"" button is hidden in editor cta","The button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",1422866498,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_description,"""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button","""Edit without login"" button is hidden in editor cta./n/nThe button ""Edit without login"" has display:none; on the editor cta. Steps to reproduce: 1. Make sure you're in alpha or anonymous editing is enabled in your configuration 2. Go to an editable page 3. Click the edit pencil Expected: You see a warning and 3 options (Edit without login, login and signup) Observed: You don't see the edit without login button",Lowest,10,1422896508,PHID-USER-c5xwrfdyp3dckkh2nkoj,resolved,TRUE,c3,1,TRUE,TRUE,-22,TRUE,"['""Edit without login"" button is hidden in editor cta.', 'The button ""Edit without login"" has display:none; on the editor cta.', 'Steps to reproduce:\n1.', ""Make sure you're in alpha or anonymous editing is enabled in your configuration\n2."", 'Go to an editable page\n3.', ""Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button""]",TRUE,1,"Click the edit pencil\n\nExpected: You see a warning and 3 options (Edit without login, login and signup)\nObserved: You don't see the edit without login button",OBSERVED BUG BEHAVIOR,, 24991,"""Edit without login"" button is hidden in editor cta","> The change will have gone out on the train since the last date you mentioned, right? I think so, unless I missed something.",1425569473,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"> The change will have gone out on the train since the last date you mentioned, right? I think so, unless I missed something.","QUOTE I think so, unless I missed something.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"['QUOTE\n\nI think so, unless I missed something.']",NA,1,"QUOTE\n\nI think so, unless I missed something.",SOCIAL CONVERSATION,, 24992,"""Edit without login"" button is hidden in editor cta","I've just very quickly verified the behaviour on http://en.wikipedia.org/wiki/Samurai?mobileaction=alpha <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for `EditorOverlay.js`. The change will have gone out on the train since the last date you mentioned, right?",1425551620,PHID-USER-w3pd7vqenmta6vpmhwcn,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"I've just very quickly verified the behaviour on http://en.wikipedia.org/wiki/Samurai?mobileaction=alpha <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for `EditorOverlay.js`. The change will have gone out on the train since the last date you mentioned, right?","I've just very quickly verified the behaviour on URL <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for CODE. The change will have gone out on the train since the last date you mentioned, right?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"[""I've just very quickly verified the behaviour on URL <20><><EFBFBD>\xa0including checking that the change is present in the source for CODE."", 'The change will have gone out on the train since the last date you mentioned, right?']",NA,1,"The change will have gone out on the train since the last date you mentioned, right?",TASK PROGRESS,, 24992,"""Edit without login"" button is hidden in editor cta","I've just very quickly verified the behaviour on http://en.wikipedia.org/wiki/Samurai?mobileaction=alpha <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for `EditorOverlay.js`. The change will have gone out on the train since the last date you mentioned, right?",1425551620,PHID-USER-w3pd7vqenmta6vpmhwcn,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"I've just very quickly verified the behaviour on http://en.wikipedia.org/wiki/Samurai?mobileaction=alpha <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for `EditorOverlay.js`. The change will have gone out on the train since the last date you mentioned, right?","I've just very quickly verified the behaviour on URL <20><><EFBFBD><EFBFBD><EFBFBD>including checking that the change is present in the source for CODE. The change will have gone out on the train since the last date you mentioned, right?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"[""I've just very quickly verified the behaviour on URL <20><><EFBFBD>\xa0including checking that the change is present in the source for CODE."", 'The change will have gone out on the train since the last date you mentioned, right?']",NA,1,I've just very quickly verified the behaviour on URL <20><><EFBFBD>\xa0including checking that the change is present in the source for CODE.,SOLUTION USAGE,, 24993,"""Edit without login"" button is hidden in editor cta","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?",1425545989,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[URL both in 1.25wmf16]]. So the bug was never deployed, right?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"['Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]].', 'The bug and its fix [[URL both in 1.25wmf16]].', 'So the bug was never deployed, right?']",NA,1,Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]].,INVESTIGATION AND EXPLORATION,, 24993,"""Edit without login"" button is hidden in editor cta","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?",1425545989,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[URL both in 1.25wmf16]]. So the bug was never deployed, right?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"['Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]].', 'The bug and its fix [[URL both in 1.25wmf16]].', 'So the bug was never deployed, right?']",NA,1,The bug and its fix [[URL both in 1.25wmf16]].,TASK PROGRESS,, 24993,"""Edit without login"" button is hidden in editor cta","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?",1425545989,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[https://wikitech.wikimedia.org/wiki/Server_Admin_Log#January_30| 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf16#MobileFrontend|were both in 1.25wmf16]]. So the bug was never deployed, right?","Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]]. The bug and its fix [[URL both in 1.25wmf16]]. So the bug was never deployed, right?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,"['Between 2015-01-29 and 2015-02-11 the only MobileFrontend SAL item I see is [[URL 19:27 logmsgbot: phuedx Synchronized php-1.25wmf15/extensions/MobileFrontend/: No-op deployment training (duration: 00m 06s)]].', 'The bug and its fix [[URL both in 1.25wmf16]].', 'So the bug was never deployed, right?']",NA,1,"So the bug was never deployed, right?",INVESTIGATION AND EXPLORATION,, 24994,"""Edit without login"" button is hidden in editor cta","Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]]",1422896618,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]]","Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-22,TRUE,"['Change 188043 merged by jenkins-bot:\nDon\'t hide ""edit without login"" button on editor cta\n\n[[GERRIT_URL]]']",NA,1,Change 188043 merged by jenkins-bot:\nDon\,TASK PROGRESS,, 24994,"""Edit without login"" button is hidden in editor cta","Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]]",1422896618,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]]","Change 188043 merged by jenkins-bot: Don't hide ""edit without login"" button on editor cta [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-22,TRUE,"['Change 188043 merged by jenkins-bot:\nDon\'t hide ""edit without login"" button on editor cta\n\n[[GERRIT_URL]]']",NA,1,edit without login,NA,, 24995,"""Edit without login"" button is hidden in editor cta","Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]] #patch-for-review",1422880620,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]] #patch-for-review","Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[GERRIT_URL]] #patch-for-review",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-22,TRUE,"['Change 188043 had a related patch set uploaded (by Florianschmidtwelzow):\nDon\'t hide ""edit without login"" button on editor cta\n\n[[GERRIT_URL]]\n\n#patch-for-review']",NA,1,Change 188043 had a related patch set uploaded (by Florianschmidtwelzow):\nDon\,TASK PROGRESS,, 24995,"""Edit without login"" button is hidden in editor cta","Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]] #patch-for-review",1422880620,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,"Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[https://gerrit.wikimedia.org/r/188043]] #patch-for-review","Change 188043 had a related patch set uploaded (by Florianschmidtwelzow): Don't hide ""edit without login"" button on editor cta [[GERRIT_URL]] #patch-for-review",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-22,TRUE,"['Change 188043 had a related patch set uploaded (by Florianschmidtwelzow):\nDon\'t hide ""edit without login"" button on editor cta\n\n[[GERRIT_URL]]\n\n#patch-for-review']",NA,1,edit without login,NA,, 24996,"""Edit without login"" button is hidden in editor cta",Caused by: https://gerrit.wikimedia.org/r/#/c/185929/,1422866532,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-swjki3cdfm27cfioa7dz,task_subcomment,Caused by: https://gerrit.wikimedia.org/r/#/c/185929/,Caused by: URL,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-22,TRUE,['Caused by: URL'],NA,1,Caused by: URL,INVESTIGATION AND EXPLORATION,, 488,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",1371265140,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-b7q472kz3l2dnhbtziiw,task_description,"VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://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","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL 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",Unbreak Now!,100,1371511467,NA,resolved,TRUE,c1,2,TRUE,FALSE,-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,VisualEditor: HTML comments are dropped from transclusion calls.,OBSERVED BUG BEHAVIOR,, 488,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",1371265140,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-b7q472kz3l2dnhbtziiw,task_description,"VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://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","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL 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",Unbreak Now!,100,1371511467,NA,resolved,TRUE,c1,2,TRUE,FALSE,-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"URL shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.",POTENTIAL NEW ISSUES AND REQUESTS,, 488,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",1371265140,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-b7q472kz3l2dnhbtziiw,task_description,"VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://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","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL 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",Unbreak Now!,100,1371511467,NA,resolved,TRUE,c1,2,TRUE,FALSE,-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"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"".",OBSERVED BUG BEHAVIOR,, 488,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",1371265140,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-b7q472kz3l2dnhbtziiw,task_description,"VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://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","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL 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",Unbreak Now!,100,1371511467,NA,resolved,TRUE,c1,2,TRUE,FALSE,-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,"These comments often have important messages to other editors, so they can not be stripped.",SOLUTION DISCUSSION,, 488,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",1371265140,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-b7q472kz3l2dnhbtziiw,task_description,"VisualEditor: HTML comments are dropped from transclusion calls./n/nhttps://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","VisualEditor: HTML comments are dropped from transclusion calls./n/nURL 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",Unbreak Now!,100,1371511467,NA,resolved,TRUE,c1,2,TRUE,FALSE,-3,NA,"['VisualEditor: HTML comments are dropped from transclusion calls.', '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.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL\nURL,OBSERVED BUG BEHAVIOR,, 489,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.",1417635932,PHID-USER-4alekd35in5tg53zpsl4,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.","verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"['verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.']",NA,0,"verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",BUG REPRODUCTION,, 490,VisualEditor: HTML comments are dropped from transclusion calls,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",1417635694,PHID-USER-4alekd35in5tg53zpsl4,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.","verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"['verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.']",NA,0,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",BUG REPRODUCTION,, 491,VisualEditor: HTML comments are dropped from transclusion calls,"That's a separate bug, will raise as such.",1372002624,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"That's a separate bug, will raise as such.","That's a separate bug, will raise as such.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"[""That's a separate bug, will raise as such.""]",NA,0,"That's a separate bug, will raise as such.",POTENTIAL NEW ISSUES AND REQUESTS,, 492,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 :)",1371996558,PHID-USER-wil4b5lylrvf3krixlkl,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"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 :)","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 :)",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,"[""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 :)""]",NA,0,"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 :)",BUG REPRODUCTION,, 493,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.",1371511467,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['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.']",NA,0,"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.",TASK PROGRESS,, 494,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.,1371465156,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-b7q472kz3l2dnhbtziiw,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.,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.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"[""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.']",NA,0,The comment appears in the template dialog and can be edited.,INVESTIGATION AND EXPLORATION,, 494,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.,1371465156,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-b7q472kz3l2dnhbtziiw,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.,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.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"[""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.']",NA,0,With experimental code disabled the template is completely untouched.,INVESTIGATION AND EXPLORATION,, 494,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.,1371465156,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-b7q472kz3l2dnhbtziiw,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.,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.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"[""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.']",NA,0,Can't reproduce in master.,BUG REPRODUCTION,, 495,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.",1371425926,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"(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.","(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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe 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.']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there.",ISSUE CONTENT MANAGEMENT,, 495,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.",1371425926,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"(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.","(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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nThe 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.']",NA,0,:-) Bug 42124 is not relevant.,ISSUE CONTENT MANAGEMENT,, 496,VisualEditor: HTML comments are dropped from transclusion calls,"[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",1371424680,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.","[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]]\n\nSee also bug 42124.'],NA,0,[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]]\n\nSee also bug 42124.,ISSUE CONTENT MANAGEMENT,, 497,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",1371424467,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,task_subcomment,"See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox","See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['See also bug 49655 and this (where Ssastry discusses it): \nWikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox'],NA,0,See also bug 49655 and this (where Ssastry discusses it): \nWikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox,ISSUE CONTENT MANAGEMENT,, 498,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.",1371420455,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,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 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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""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.']",NA,0,"Ed, can you confirm at your end if this is a DM issue or a Parsoid one?",INVESTIGATION AND EXPLORATION,, 498,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.",1371420455,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,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 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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""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.']",NA,0,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 (?).,OBSERVED BUG BEHAVIOR,, 498,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.",1371420455,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,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 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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""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.']",NA,0,merged with the following transclusion.,TASK PROGRESS,, 498,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.",1371420455,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,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 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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""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.']",NA,0,"Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?).",OBSERVED BUG BEHAVIOR,, 498,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.",1371420455,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-b7q472kz3l2dnhbtziiw,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 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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""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.']",NA,0,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?),INVESTIGATION AND EXPLORATION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"At the time of this discussion by VE developers, \n[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved.",INVESTIGATION AND EXPLORATION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.,OBSERVED BUG BEHAVIOR,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"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..",SOLUTION DISCUSSION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,Page notices and edit notices are for a whole page or section.,OBSERVED BUG BEHAVIOR,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,For more info: \n[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives.,ISSUE CONTENT MANAGEMENT,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime.",MOTIVATION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit.",SOLUTION DISCUSSION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,VE should not be doing anything within templates.,EXPECTED BEHAVIOR,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,Templates are too complex for VE to meddle with in the slightest way.,SOLUTION DISCUSSION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,VE should not even remove spaces in templates.,EXPECTED BEHAVIOR,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"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.",SOLUTION DISCUSSION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,But why bother?,MOTIVATION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,"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?",SOLUTION DISCUSSION,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,So one can read the hidden note in the popup.,SOLUTION USAGE,, 499,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.",1371269621,PHID-USER-ebwxbdwkoxprr4cvvjvy,PHID-TASK-b7q472kz3l2dnhbtziiw,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['At the time of this discussion by VE developers, \n[[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: \n[[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.']",NA,0,Kind of like how reference tooltips work.,EXPECTED BEHAVIOR,, 524,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",1371213300,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-m3novk5xasw5lqvg62ye,task_description,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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",Unbreak Now!,100,1371235366,NA,resolved,TRUE,c1,2,FALSE,FALSE,-3,NA,"['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: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion.,OBSERVED BUG BEHAVIOR,, 524,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",1371213300,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-m3novk5xasw5lqvg62ye,task_description,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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",Unbreak Now!,100,1371235366,NA,resolved,TRUE,c1,2,FALSE,FALSE,-3,NA,"['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: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page.,OBSERVED BUG BEHAVIOR,, 524,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",1371213300,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-m3novk5xasw5lqvg62ye,task_description,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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","New deployment of Parsoid leads to HTML insertion - needs deployed code reversion./n/nI 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",Unbreak Now!,100,1371235366,NA,resolved,TRUE,c1,2,FALSE,FALSE,-3,NA,"['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: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,See this revision: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: critical,OBSERVED BUG BEHAVIOR,, 525,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 50049 has been marked as a duplicate of this bug. ***,1372004983,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,*** Bug 50049 has been marked as a duplicate of this bug. ***,*** Bug 50049 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['*** Bug 50049 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50049 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 525,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 50049 has been marked as a duplicate of this bug. ***,1372004983,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,*** Bug 50049 has been marked as a duplicate of this bug. ***,*** Bug 50049 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['*** Bug 50049 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 526,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Yes, <https://bugzilla.wikimedia.org/show_bug.cgi?id=49701>. It is apparently fixed.",1371657346,PHID-USER-vyidforzdhnrsoweujao,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Yes, <https://bugzilla.wikimedia.org/show_bug.cgi?id=49701>. It is apparently fixed.","Yes, <URL It is apparently fixed.",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,"['Yes, <URL It is apparently fixed.']",NA,0,"Yes, <URL It is apparently fixed.",TASK PROGRESS,, 527,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,1371652833,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['Did you open a new bug?', 'If so could you please link it?', 'I have someone with a similar issue.']",NA,0,Did you open a new bug?,ISSUE CONTENT MANAGEMENT,, 527,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,1371652833,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['Did you open a new bug?', 'If so could you please link it?', 'I have someone with a similar issue.']",NA,0,If so could you please link it?,ISSUE CONTENT MANAGEMENT,, 527,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,1371652833,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,Did you open a new bug? If so could you please link it? I have someone with a similar issue.,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['Did you open a new bug?', 'If so could you please link it?', 'I have someone with a similar issue.']",NA,0,I have someone with a similar issue.,MOTIVATION,, 528,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.",1371483619,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.","Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['Ah, sorry, I missed the tag.', 'I think you should; this is certainly something different than what was happening here.']",NA,0,"Ah, sorry, I missed the tag.",SOCIAL CONVERSATION,, 528,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.",1371483619,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.","Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"['Ah, sorry, I missed the tag.', 'I think you should; this is certainly something different than what was happening here.']",NA,0,I think you should; this is certainly something different than what was happening here.,ISSUE CONTENT MANAGEMENT,, 529,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,It has the VisualEditor tag and was reported in the feedback page <http://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AEditor_Visual%2FComent%C3%A1rios&diff=36129760&oldid=36054006>. Should I open a new bug?,1371482523,PHID-USER-vyidforzdhnrsoweujao,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,It has the VisualEditor tag and was reported in the feedback page <http://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AEditor_Visual%2FComent%C3%A1rios&diff=36129760&oldid=36054006>. Should I open a new bug?,It has the VisualEditor tag and was reported in the feedback page <URL Should I open a new bug?,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,['It has the VisualEditor tag and was reported in the feedback page <URL Should I open a new bug?'],NA,0,It has the VisualEditor tag and was reported in the feedback page <URL Should I open a new bug?,ISSUE CONTENT MANAGEMENT,, 530,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.",1371480754,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.","It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-2,NA,"[""It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.""]",NA,0,"It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.",OBSERVED BUG BEHAVIOR,, 531,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Not sure if this is related: <https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, but that edit was made today.",1371477080,PHID-USER-vyidforzdhnrsoweujao,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Not sure if this is related: <https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, but that edit was made today.",Not sure if this is related: <URL but that edit was made today.,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,['Not sure if this is related: <URL but that edit was made today.'],NA,0,Not sure if this is related: <URL but that edit was made today.,INVESTIGATION AND EXPLORATION,, 532,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.",1371235366,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.","To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want)."", ""Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.""]",NA,0,"To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want).",INVESTIGATION AND EXPLORATION,, 532,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.",1371235366,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.","To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want). Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"[""To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want)."", ""Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.""]",NA,0,"Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.",TASK PROGRESS,, 533,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",1371223781,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.","It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"['It looks like an update to the libraries Parsoid depends on might have caused this issue.', 'It would have been visible in the diff, but since the user is not seeing that by default any more few noticed.', 'Parsoid is rolled back, so this issue should be fixed.']",NA,0,It looks like an update to the libraries Parsoid depends on might have caused this issue.,INVESTIGATION AND EXPLORATION,, 533,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",1371223781,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.","It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"['It looks like an update to the libraries Parsoid depends on might have caused this issue.', 'It would have been visible in the diff, but since the user is not seeing that by default any more few noticed.', 'Parsoid is rolled back, so this issue should be fixed.']",NA,0,"It would have been visible in the diff, but since the user is not seeing that by default any more few noticed.",OBSERVED BUG BEHAVIOR,, 533,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",1371223781,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.","It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed. Parsoid is rolled back, so this issue should be fixed.",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-3,NA,"['It looks like an update to the libraries Parsoid depends on might have caused this issue.', 'It would have been visible in the diff, but since the user is not seeing that by default any more few noticed.', 'Parsoid is rolled back, so this issue should be fixed.']",NA,0,"Parsoid is rolled back, so this issue should be fixed.",TASK PROGRESS,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.",OBSERVED BUG BEHAVIOR,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"Well, I added text to different sections.",BUG REPRODUCTION,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.",BUG REPRODUCTION,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,I\,NA,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,ve seen.........,NA,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled.",OBSERVED BUG BEHAVIOR,, 534,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: (One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,Save page,NA,, 535,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",1371221206,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for.', ""I'm going to go round and notify people now :)""]",NA,0,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for.",CONTRIBUTION AND COMMITMENT,, 535,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",1371221206,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for.', ""I'm going to go round and notify people now :)""]",NA,0,I'm going to go round and notify people now :),CONTRIBUTION AND COMMITMENT,, 536,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),1371221157,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)'],NA,0,Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),INVESTIGATION AND EXPLORATION,, 537,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),1371221153,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)'],NA,0,Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa),INVESTIGATION AND EXPLORATION,, 538,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",1371220263,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"[""A note; I've just spoken to James F; a fix to this is highest-priority."", ""I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).""]",NA,0,A note; I've just spoken to James F; a fix to this is highest-priority.,MOTIVATION,, 538,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",1371220263,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"[""A note; I've just spoken to James F; a fix to this is highest-priority."", ""I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).""]",NA,0,"I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",SOCIAL CONVERSATION,, 539,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"(In reply to comment #3) > 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",1371219908,PHID-USER-jtxavgb3caz53o45csni,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"(In reply to comment #3) > 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","(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",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"[""(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nIf that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it):\n\nJun 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\n...\nJun 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""]",NA,0,(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nIf that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it):\n\nJun 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\n...\nJun 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,INVESTIGATION AND EXPLORATION,, 540,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",1371219726,PHID-USER-3qvsqam4jxugqg2l7qpw,PHID-TASK-m3novk5xasw5lqvg62ye,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, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","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",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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']",NA,0,"Yes, first time I tried the new VisualEditor.",BUG REPRODUCTION,, 540,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",1371219726,PHID-USER-3qvsqam4jxugqg2l7qpw,PHID-TASK-m3novk5xasw5lqvg62ye,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, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","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",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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']",NA,0,My user page is live and I still left the HTML as an example.,OBSERVED BUG BEHAVIOR,, 540,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",1371219726,PHID-USER-3qvsqam4jxugqg2l7qpw,PHID-TASK-m3novk5xasw5lqvg62ye,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, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","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",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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']",NA,0,"Tried a few more times to blank page with VE, it is real ugly.",BUG REPRODUCTION,, 540,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",1371219726,PHID-USER-3qvsqam4jxugqg2l7qpw,PHID-TASK-m3novk5xasw5lqvg62ye,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, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236","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",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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']",NA,0,"HTML leaks on HTML leaks on HTML leaks with each new save, URL",BUG REPRODUCTION,, 541,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).,1371217642,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,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).,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).,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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).']",NA,0,This is occurring fairly widely and I have a lot of reports.,OBSERVED BUG BEHAVIOR,, 541,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).,1371217642,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-m3novk5xasw5lqvg62ye,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).,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).,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['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).']",NA,0,Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).,ACTION ON ISSUE ,, 542,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,1371215939,PHID-USER-3uecblbxq24ycewm2cog,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,Issue started ~ 11:37 UTC today per https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges,Issue started ~ 11:37 UTC today per URL,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['Issue started ~ 11:37 UTC today per URL'],NA,0,Issue started ~ 11:37 UTC today per URL,INVESTIGATION AND EXPLORATION,, 543,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",1371214660,PHID-USER-3uecblbxq24ycewm2cog,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,"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","More of this: URL URL",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['More of this:\n\nURL\n\nURL'],NA,0,More of this:\n\nURL\n\nURL,NA,, 544,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 49573 has been marked as a duplicate of this bug. ***,1371214602,PHID-USER-3uecblbxq24ycewm2cog,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,*** Bug 49573 has been marked as a duplicate of this bug. ***,*** Bug 49573 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['*** Bug 49573 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 49573 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 544,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 49573 has been marked as a duplicate of this bug. ***,1371214602,PHID-USER-3uecblbxq24ycewm2cog,PHID-TASK-m3novk5xasw5lqvg62ye,task_subcomment,*** Bug 49573 has been marked as a duplicate of this bug. ***,*** Bug 49573 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,"['*** Bug 49573 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 629,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_description,"VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1367602898,NA,resolved,TRUE,c1,1,TRUE,FALSE,-9,NA,"['VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box.,EXPECTED BEHAVIOR,, 629,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_description,"VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1367602898,NA,resolved,TRUE,c1,1,TRUE,FALSE,-9,NA,"['VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,This is a Bad Thing(tm).,SOCIAL CONVERSATION,, 629,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_description,"VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1367602898,NA,resolved,TRUE,c1,1,TRUE,FALSE,-9,NA,"['VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: critical,OBSERVED BUG BEHAVIOR,, 629,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",1367266320,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_description,"VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box./n/nCurrently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm). -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1367602898,NA,resolved,TRUE,c1,1,TRUE,FALSE,-9,NA,"['VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box.', ""Currently we don't alert users that they're outing their IP when they save."", 'This is a Bad Thing(tm).', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Currently we don't alert users that they're outing their IP when they save.,OBSERVED BUG BEHAVIOR,, 630,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,I see - wan't looking at main namespace.,1367604012,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,I see - wan't looking at main namespace.,I see - wan't looking at main namespace.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"[""I see - wan't looking at main namespace.""]",NA,0,I see - wan't looking at main namespace.,BUG REPRODUCTION,, 631,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,Merged and will go out with wmf4.,1367602898,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,Merged and will go out with wmf4.,Merged and will go out with wmf4.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,['Merged and will go out with wmf4.'],NA,0,Merged and will go out with wmf4.,TASK PROGRESS,, 632,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).",1367599367,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,"(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).","(In reply to comment #4) QUOTE Compare URL with URL in an isolated browser (e.g. Chrome Incognito).",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"['(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g.', 'Chrome Incognito).']",NA,0,(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g.,BUG REPRODUCTION,, 632,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).",1367599367,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,"(In reply to comment #4) > mediawiki.org? I don't see it there. Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).","(In reply to comment #4) QUOTE Compare URL with URL in an isolated browser (e.g. Chrome Incognito).",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"['(In reply to comment #4)\nQUOTE\n\nCompare URL with URL in an isolated browser (e.g.', 'Chrome Incognito).']",NA,0,Chrome Incognito).,NA,, 633,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,mediawiki.org? I don't see it there.,1367598917,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,mediawiki.org? I don't see it there.,mediawiki.org? I don't see it there.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"['mediawiki.org?', ""I don't see it there.""]",NA,0,mediawiki.org?,NA,, 633,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,mediawiki.org? I don't see it there.,1367598917,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,mediawiki.org? I don't see it there.,mediawiki.org? I don't see it there.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"['mediawiki.org?', ""I don't see it there.""]",NA,0,I don't see it there.,BUG REPRODUCTION,, 634,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",1367594947,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,"(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)","(In reply to comment #2) QUOTE QUOTE QUOTE Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference."", ':-)']",NA,0,:-),SOCIAL CONVERSATION,, 634,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",1367594947,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,"(In reply to comment #2) > Currently the extension doesn't let anon editors use it at all ( > $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've > put in a fix for when we do. Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)","(In reply to comment #2) QUOTE QUOTE QUOTE Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference."", ':-)']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nExcept for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference.",SOLUTION USAGE,, 635,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,"Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.",1367577948,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,"Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.","Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-9,NA,"[""Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.""]",NA,0,"Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.",CONTRIBUTION AND COMMITMENT,, 636,VisualEditor: Message <anoneditwarning> should be displayed for anonymous users in the alerts box,Related URL: https://gerrit.wikimedia.org/r/62143 (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0),1367577674,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-5bkkyo5d2dquufftw2sz,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/62143 (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0),Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0),NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-9,NA,['Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)'],NA,0,Related URL: GERRIT_URL (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0),INVESTIGATION AND EXPLORATION,, 843,VisualEditor: Edit summary field loses focus when pasting (Firefox),"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_description,"VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1393634141,NA,resolved,TRUE,c1,3,FALSE,FALSE,10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,VisualEditor: Edit summary field loses focus when pasting (Firefox).,OBSERVED BUG BEHAVIOR,, 843,VisualEditor: Edit summary field loses focus when pasting (Firefox),"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_description,"VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1393634141,NA,resolved,TRUE,c1,3,FALSE,FALSE,10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.",OBSERVED BUG BEHAVIOR,, 843,VisualEditor: Edit summary field loses focus when pasting (Firefox),"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_description,"VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1393634141,NA,resolved,TRUE,c1,3,FALSE,FALSE,10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,Possibly related to bug 53632??,INVESTIGATION AND EXPLORATION,, 843,VisualEditor: Edit summary field loses focus when pasting (Firefox),"When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",1378792920,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_description,"VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Edit summary field loses focus when pasting (Firefox)./n/nWhen pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus. Possibly related to bug 53632?? -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1393634141,NA,resolved,TRUE,c1,3,FALSE,FALSE,10,NA,"['VisualEditor: Edit summary field loses focus when pasting (Firefox).', 'When pasting some text into the edit summary box in Firefox 23 (via Ctrl+V or context menu), the paste occurs, but the edit summary box loses focus.', 'Possibly related to bug 53632??', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 844,VisualEditor: Edit summary field loses focus when pasting (Firefox),"Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",1393634141,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_subcomment,"Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,34,NA,"['Now that the edit summary is in its own window, this bug has gone away.', ""I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.""]",NA,0,"Now that the edit summary is in its own window, this bug has gone away.",BUG REPRODUCTION,, 844,VisualEditor: Edit summary field loses focus when pasting (Firefox),"Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",1393634141,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-pdpn7hvlculri4ccy42t,task_subcomment,"Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.","Now that the edit summary is in its own window, this bug has gone away. I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,34,NA,"['Now that the edit summary is in its own window, this bug has gone away.', ""I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.""]",NA,0,I don't know whether the plan is to eventually return to the edit confirmation flyout - if so this bug may well reappear.,POTENTIAL NEW ISSUES AND REQUESTS,X, 882,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_description,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL",Needs Triage,90,1390023864,NA,declined,TRUE,c1,3,FALSE,FALSE,8,NA,"['VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags.', 'There is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags.",EXPECTED BEHAVIOR,, 882,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_description,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL",Needs Triage,90,1390023864,NA,declined,TRUE,c1,3,FALSE,FALSE,8,NA,"['VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags.', 'There is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,There is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace.,SOLUTION USAGE,, 882,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_description,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL",Needs Triage,90,1390023864,NA,declined,TRUE,c1,3,FALSE,FALSE,8,NA,"['VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags.', 'There is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,"However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.",SOLUTION USAGE,, 882,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","There is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603",1378049580,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_description,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=571087443#nowiki_tags about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49806 https://bugzilla.wikimedia.org/show_bug.cgi?id=49603","VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags./n/nThere is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace. However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit. They can't find the nowiki tag, as it is invisible."" -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL URL",Needs Triage,90,1390023864,NA,declined,TRUE,c1,3,FALSE,FALSE,8,NA,"['VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags.', 'There is discussion at URL about using the edit filter to block edits adding the <nowiki /> tag in mainspace.', 'However it was pointed out that ""the user probably has no way to know what they need to fix in order to resubmit their edit.', 'They can\'t find the nowiki tag, as it is invisible.""', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL']",FALSE,0,They can\,NA,, 883,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).",1390023864,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_subcomment,"WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).","WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,28,NA,"['WONTFIXing this bug instead:\n\n<nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed.', 'Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).']",NA,0,"WONTFIXing this bug instead:\n\n<nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed.",ACTION ON ISSUE,, 883,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).",1390023864,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_subcomment,"WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).","WONTFIXing this bug instead: <nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed. Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,28,NA,"['WONTFIXing this bug instead:\n\n<nowiki> is fundamentally an artefact of wikitext that users should be (blissfully) unaware of, and Parsoid should ""just make work"" as needed.', 'Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).']",NA,0,"Right now this is generally true, and it will get better, not worse, in the future, so this is not needed (which is good, because VisualEditor has no way of knowing whilst a user is editing whether Parsoid will decide to put a <nowiki> in).",FUTURE PLANS,, 884,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","Gah, sorry, wrong bug.",1390023748,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_subcomment,"Gah, sorry, wrong bug.","Gah, sorry, wrong bug.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,28,NA,"['Gah, sorry, wrong bug.']",NA,0,"Gah, sorry, wrong bug.",SOCIAL CONVERSATION,, 885,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",1390023708,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_subcomment,"This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***","This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,28,NA,"['This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381.', '*** This bug has been marked as a duplicate of bug 56381 ***']",NA,0,"This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381.",ACTION ON ISSUE,, 885,"VisualEditor: Show and make editable <nowiki>, </nowiki> and <nowiki /> tags","This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",1390023708,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-brld2i7xjlh2vp4m2jxn,task_subcomment,"This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***","This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381. *** This bug has been marked as a duplicate of bug 56381 ***",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,28,NA,"['This is because <nowiki /s> (unlike <nowiki>s) are ""meta"" items in the DOM rather than things VE can edit; merging with bug 56381.', '*** This bug has been marked as a duplicate of bug 56381 ***']",NA,0,*** This bug has been marked as a duplicate of bug 56381 ***,ISSUE CONTENT MANAGEMENT,, 1319,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}",1374481140,PHID-USER-fgjrqsoj4hk6ezzjdea4,PHID-TASK-kuzyc5hs4c2r4b2fex4f,task_description,"VE: Page settings: Languages list cut off./n/nScreenshot 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}","VE: Page settings: Languages list cut off./n/nScreenshot 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}",Needs Triage,90,1374489509,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,VE: Page settings: Languages list cut off.,OBSERVED BUG BEHAVIOR,, 1319,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}",1374481140,PHID-USER-fgjrqsoj4hk6ezzjdea4,PHID-TASK-kuzyc5hs4c2r4b2fex4f,task_description,"VE: Page settings: Languages list cut off./n/nScreenshot 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}","VE: Page settings: Languages list cut off./n/nScreenshot 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}",Needs Triage,90,1374489509,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,"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\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.",OBSERVED BUG BEHAVIOR,, 1319,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}",1374481140,PHID-USER-fgjrqsoj4hk6ezzjdea4,PHID-TASK-kuzyc5hs4c2r4b2fex4f,task_description,"VE: Page settings: Languages list cut off./n/nScreenshot 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}","VE: Page settings: Languages list cut off./n/nScreenshot 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}",Needs Triage,90,1374489509,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nOriginal Bug title: VE: Page settings: Languages list cut off\n\nIn the page settings dialog, the languages list is not completely visible.', 'This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501}']",TRUE,0,This is due to the higher CSS selector precedence of \n.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout (setting overflow:hidden) \nover \n.ve-ui-panelLayout-scrollable (setting overflow-y:auto)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11501},INVESTIGATION AND EXPLORATION,, 1320,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",1374513446,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-kuzyc5hs4c2r4b2fex4f,task_subcomment,"Change 75083 abandoned by Rillke: Adding important to overflow:auto on scrollable elements Reason: Fixed by If2d5ec3168a874eb4f856450583d6c89967513df https://gerrit.wikimedia.org/r/75083","Change 75083 abandoned by Rillke: Adding important to overflow:auto on scrollable elements Reason: Fixed by If2d5ec3168a874eb4f856450583d6c89967513df GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,3,NA,['Change 75083 abandoned by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nReason:\nFixed by If2d5ec3168a874eb4f856450583d6c89967513df\n\nGERRIT_URL'],NA,0,Change 75083 abandoned by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nReason:\nFixed by If2d5ec3168a874eb4f856450583d6c89967513df\n\nGERRIT_URL,TASK PROGRESS,, 1321,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 ***",1374489509,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-kuzyc5hs4c2r4b2fex4f,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 ***","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"[""I'm pretty sure it's the same issue as on bug 51739."", '*** This bug has been marked as a duplicate of bug 51739 ***']",NA,0,*** This bug has been marked as a duplicate of bug 51739 ***,ISSUE CONTENT MANAGEMENT,, 1321,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 ***",1374489509,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-kuzyc5hs4c2r4b2fex4f,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 ***","I'm pretty sure it's the same issue as on bug 51739. *** This bug has been marked as a duplicate of bug 51739 ***",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"[""I'm pretty sure it's the same issue as on bug 51739."", '*** This bug has been marked as a duplicate of bug 51739 ***']",NA,0,I'm pretty sure it's the same issue as on bug 51739.,ISSUE CONTENT MANAGEMENT,, 1322,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",1374487397,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-kuzyc5hs4c2r4b2fex4f,task_subcomment,"Change 75083 had a related patch set uploaded by Rillke: Adding important to overflow:auto on scrollable elements https://gerrit.wikimedia.org/r/75083","Change 75083 had a related patch set uploaded by Rillke: Adding important to overflow:auto on scrollable elements GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,3,NA,['Change 75083 had a related patch set uploaded by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nGERRIT_URL'],NA,0,Change 75083 had a related patch set uploaded by Rillke:\nAdding important to overflow:auto on scrollable elements\n\nGERRIT_URL,TASK PROGRESS,, 1592,Nested <nowiki>s considered harmful,"Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_description,"Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1373314749,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"['Nested <nowiki>s considered harmful.', 'Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,Nested <nowiki>s considered harmful.,SOLUTION DISCUSSION,, 1592,Nested <nowiki>s considered harmful,"Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_description,"Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1373314749,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"['Nested <nowiki>s considered harmful.', 'Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.",INVESTIGATION AND EXPLORATION,, 1592,Nested <nowiki>s considered harmful,"Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387",1373055060,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_description,"Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Your_Face_Sounds_Familiar_%28UK_TV_series%29&diff=562149606&oldid=562149387","Nested <nowiki>s considered harmful./n/nSometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-) -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1373314749,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"['Nested <nowiki>s considered harmful.', 'Sometimes Parsoid will wrap a <nowiki> around an existing <nowiki>; this is generally a bad idea, even if we have dirtied the reference in VisualEditor.', ':-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,:-)\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL,OBSERVED BUG BEHAVIOR,, 1593,Nested <nowiki>s considered harmful,*** Bug 50724 has been marked as a duplicate of this bug. ***,1373637242,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,*** Bug 50724 has been marked as a duplicate of this bug. ***,*** Bug 50724 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['*** Bug 50724 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50724 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 1593,Nested <nowiki>s considered harmful,*** Bug 50724 has been marked as a duplicate of this bug. ***,1373637242,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,*** Bug 50724 has been marked as a duplicate of this bug. ***,*** Bug 50724 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['*** Bug 50724 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 1594,Nested <nowiki>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",1373473754,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,"Change 72971 merged by jenkins-bot: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params https://gerrit.wikimedia.org/r/72971","Change 72971 merged by jenkins-bot: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['Change 72971 merged by jenkins-bot:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL'],NA,0,Change 72971 merged by jenkins-bot:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL,TASK PROGRESS,, 1595,Nested <nowiki>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",1373470917,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,"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","Change 72971 had a related patch set uploaded by Subramanya Sastry: Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['Change 72971 had a related patch set uploaded by Subramanya Sastry:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL'],NA,0,Change 72971 had a related patch set uploaded by Subramanya Sastry:\nTry #2: (Bug 50835) Dont nowiki escape already escaped tpl params\n\nGERRIT_URL,TASK PROGRESS,, 1596,Nested <nowiki>s considered harmful,"Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230",1373307265,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,"Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params https://gerrit.wikimedia.org/r/72230","Change 72230 merged by jenkins-bot: (Bug 50835) Dont nowiki escape already escaped template params GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['Change 72230 merged by jenkins-bot:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL'],NA,0,Change 72230 merged by jenkins-bot:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL,TASK PROGRESS,, 1597,Nested <nowiki>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",1373065523,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-lb7abq7fkyxs3qzwp4ty,task_subcomment,"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","Change 72230 had a related patch set uploaded by Subramanya Sastry: (Bug 50835) Dont nowiki escape already escaped template params GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,0,NA,['Change 72230 had a related patch set uploaded by Subramanya Sastry:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL'],NA,0,Change 72230 had a related patch set uploaded by Subramanya Sastry:\n(Bug 50835) Dont nowiki escape already escaped template params\n\nGERRIT_URL,TASK PROGRESS,, 1809,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",1372280520,PHID-USER-ttyyrgsrkyonct7hizgv,PHID-TASK-ytqjgzoe2nidan525q6p,task_description,"Unwanted Removal of text formatting./n/nIn 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","Unwanted Removal of text formatting./n/nIn 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",Needs Triage,90,1372284454,NA,resolved,TRUE,c1,2,FALSE,FALSE,-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,Unwanted Removal of text formatting.,OBSERVED BUG BEHAVIOR,, 1809,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",1372280520,PHID-USER-ttyyrgsrkyonct7hizgv,PHID-TASK-ytqjgzoe2nidan525q6p,task_description,"Unwanted Removal of text formatting./n/nIn 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","Unwanted Removal of text formatting./n/nIn 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",Needs Triage,90,1372284454,NA,resolved,TRUE,c1,2,FALSE,FALSE,-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).,OBSERVED BUG BEHAVIOR,, 1809,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",1372280520,PHID-USER-ttyyrgsrkyonct7hizgv,PHID-TASK-ytqjgzoe2nidan525q6p,task_description,"Unwanted Removal of text formatting./n/nIn 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","Unwanted Removal of text formatting./n/nIn 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",Needs Triage,90,1372284454,NA,resolved,TRUE,c1,2,FALSE,FALSE,-1,NA,"['Unwanted Removal of text formatting.', 'In this edit:URL\n\nBold/italic formatting was removed by an unrelated action (addition of text).', ""See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major""]",TRUE,0,See editor's description here:URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 1810,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 ***",1372284454,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ytqjgzoe2nidan525q6p,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 ***","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 ***",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['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 ***']",NA,0,"Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug.",ISSUE CONTENT MANAGEMENT,, 1810,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 ***",1372284454,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ytqjgzoe2nidan525q6p,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 ***","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 ***",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['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 ***']",NA,0,"Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!",MOTIVATION,, 1810,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 ***",1372284454,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ytqjgzoe2nidan525q6p,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 ***","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 ***",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['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 ***']",NA,0,*** This bug has been marked as a duplicate of bug 50068 ***,ISSUE CONTENT MANAGEMENT,, 1811,Unwanted Removal of text formatting,Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931,1372283768,PHID-USER-ttyyrgsrkyonct7hizgv,PHID-TASK-ytqjgzoe2nidan525q6p,task_subcomment,Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931,Duplicated here: URL,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-1,NA,['Duplicated here: URL'],NA,0,Duplicated here: URL,BUG REPRODUCTION,, 2061,"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",1369114380,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_description,"VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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",Needs Triage,90,1369114571,NA,resolved,TRUE,c1,1,FALSE,FALSE,-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing 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.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor misrepresents linked files as embedded inline, when editing.",OBSERVED BUG BEHAVIOR,, 2061,"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",1369114380,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_description,"VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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",Needs Triage,90,1369114571,NA,resolved,TRUE,c1,1,FALSE,FALSE,-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing 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.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"**Author:** CODE\n\n**Description:**\nPlacing a colon before a File: link in MediaWiki should link to the file, without displaying it in the page.",OBSERVED BUG BEHAVIOR,, 2061,"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",1369114380,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_description,"VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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",Needs Triage,90,1369114571,NA,resolved,TRUE,c1,1,FALSE,FALSE,-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing 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.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"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.",OBSERVED BUG BEHAVIOR,, 2061,"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",1369114380,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_description,"VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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",Needs Triage,90,1369114571,NA,resolved,TRUE,c1,1,FALSE,FALSE,-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing 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.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,(Screenshots of the error and associated markup to be attached.),OBSERVED BUG BEHAVIOR,, 2061,"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",1369114380,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_description,"VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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","VisualEditor misrepresents linked files as embedded inline, when editing./n/n**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",Needs Triage,90,1369114571,NA,resolved,TRUE,c1,1,FALSE,FALSE,-6,NA,"['VisualEditor misrepresents linked files as embedded inline, when editing.', '**Author:** CODE\n\n**Description:**\nPlacing 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.)', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 2062,"VisualEditor misrepresents linked files as embedded inline, when editing"," *** This bug has been marked as a duplicate of bug 48387 ***",1369114571,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-6nrh4cee4ez6cwykweo5,task_subcomment," *** This bug has been marked as a duplicate of bug 48387 ***"," *** This bug has been marked as a duplicate of bug 48387 ***",NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-6,NA,['\n\n*** This bug has been marked as a duplicate of bug 48387 ***'],NA,0,\n\n*** This bug has been marked as a duplicate of bug 48387 ***,ISSUE CONTENT MANAGEMENT,, 2063,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Screenshot of markup **Attached**: {F10438}",1369114456,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_subcomment,"**swalling** wrote: Screenshot of markup **Attached**: {F10438}","**swalling** wrote: Screenshot of markup **Attached**: {F10438}",NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-6,NA,['**swalling** wrote:\n\nScreenshot of markup\n\n**Attached**: {F10438}'],NA,0,**swalling** wrote:\n\nScreenshot of markup\n\n**Attached**: {F10438},INVESTIGATION AND EXPLORATION,, 2064,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",1369114431,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6nrh4cee4ez6cwykweo5,task_subcomment,"**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-6,NA,"['**swalling** wrote:\n\nEdit mode, with incorrect thumbnails\n\n**Attached**: {F10437}']",NA,0,"**swalling** wrote:\n\nEdit mode, with incorrect thumbnails\n\n**Attached**: {F10437}",OBSERVED BUG BEHAVIOR,, 2173,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",1360879800,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2lufxleaemvynes2b2da,task_description,"Parsoid: Tables don't round-trip cleanly./n/nSee 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","Parsoid: Tables don't round-trip cleanly./n/nSee 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",Needs Triage,90,1360889187,NA,declined,TRUE,c1,1,FALSE,FALSE,-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", '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\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,See URL for example.,BUG REPRODUCTION,, 2173,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",1360879800,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2lufxleaemvynes2b2da,task_description,"Parsoid: Tables don't round-trip cleanly./n/nSee 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","Parsoid: Tables don't round-trip cleanly./n/nSee 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",Needs Triage,90,1360889187,NA,declined,TRUE,c1,1,FALSE,FALSE,-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", '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\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"* border=""1"" is normalized to border=1, but only in the table\",INVESTIGATION AND EXPLORATION,, 2173,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",1360879800,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2lufxleaemvynes2b2da,task_description,"Parsoid: Tables don't round-trip cleanly./n/nSee 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","Parsoid: Tables don't round-trip cleanly./n/nSee 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",Needs Triage,90,1360889187,NA,declined,TRUE,c1,1,FALSE,FALSE,-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", '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\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0," attributes\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal",OBSERVED BUG BEHAVIOR,, 2173,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",1360879800,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2lufxleaemvynes2b2da,task_description,"Parsoid: Tables don't round-trip cleanly./n/nSee 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","Parsoid: Tables don't round-trip cleanly./n/nSee 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",Needs Triage,90,1360889187,NA,declined,TRUE,c1,1,FALSE,FALSE,-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", '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\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Parsoid: Tables don't round-trip cleanly.,OBSERVED BUG BEHAVIOR,, 2173,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",1360879800,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2lufxleaemvynes2b2da,task_description,"Parsoid: Tables don't round-trip cleanly./n/nSee 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","Parsoid: Tables don't round-trip cleanly./n/nSee 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",Needs Triage,90,1360889187,NA,declined,TRUE,c1,1,FALSE,FALSE,-20,NA,"[""Parsoid: Tables don't round-trip cleanly."", '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\n* | rowspan=""3"" is normalized to |rowspan=""3""\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,(This URL currently doesn't work because the /mw prefix disappeared in a recent change.),OBSERVED BUG BEHAVIOR,, 2174,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.",1360889187,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-2lufxleaemvynes2b2da,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-20,NA,"['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.""]",NA,0,"The first normalization is actually the other way around: border=1 is normalized to border=""1"".",INVESTIGATION AND EXPLORATION,, 2174,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.",1360889187,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-2lufxleaemvynes2b2da,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-20,NA,"['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.""]",NA,0,"This is the expected degree of normalization for non-selective serialization, so closing as wontfix.",ACTION ON ISSUE,, 2174,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.",1360889187,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-2lufxleaemvynes2b2da,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-20,NA,"['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.""]",NA,0,"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.",FUTURE PLANS,, 2267,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",1355175300,PHID-USER-mpfqwllylfkzpcgkdkvc,PHID-TASK-hydd4sggtsrxlgqhafqc,task_description,"VisualEditor: Inspector doesn't open properly./n/nWhen 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","VisualEditor: Inspector doesn't open properly./n/nWhen 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",Needs Triage,90,1355189209,NA,resolved,TRUE,c1,0,FALSE,FALSE,-29,NA,"[""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."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 2267,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",1355175300,PHID-USER-mpfqwllylfkzpcgkdkvc,PHID-TASK-hydd4sggtsrxlgqhafqc,task_description,"VisualEditor: Inspector doesn't open properly./n/nWhen 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","VisualEditor: Inspector doesn't open properly./n/nWhen 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",Needs Triage,90,1355189209,NA,resolved,TRUE,c1,0,FALSE,FALSE,-29,NA,"[""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."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,VisualEditor: Inspector doesn't open properly.,OBSERVED BUG BEHAVIOR,, 2267,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",1355175300,PHID-USER-mpfqwllylfkzpcgkdkvc,PHID-TASK-hydd4sggtsrxlgqhafqc,task_description,"VisualEditor: Inspector doesn't open properly./n/nWhen 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","VisualEditor: Inspector doesn't open properly./n/nWhen 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",Needs Triage,90,1355189209,NA,resolved,TRUE,c1,0,FALSE,FALSE,-29,NA,"[""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."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"When you select backwards, the inspector doesn't open when you make something a link (using toolbar or command+k) and when it does open (by clicking the link icon in the context menu) the link suggestions show up in the wrong place.",OBSERVED BUG BEHAVIOR,, 2268,VisualEditor: Inspector doesn't open properly,*** Bug 37856 has been marked as a duplicate of this bug. ***,1355350453,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-hydd4sggtsrxlgqhafqc,task_subcomment,*** Bug 37856 has been marked as a duplicate of this bug. ***,*** Bug 37856 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-29,NA,"['*** Bug 37856 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 37856 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 2268,VisualEditor: Inspector doesn't open properly,*** Bug 37856 has been marked as a duplicate of this bug. ***,1355350453,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-hydd4sggtsrxlgqhafqc,task_subcomment,*** Bug 37856 has been marked as a duplicate of this bug. ***,*** Bug 37856 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-29,NA,"['*** Bug 37856 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 2269,VisualEditor: Inspector doesn't open properly,Fixed in gerrit 37945.,1355176593,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-hydd4sggtsrxlgqhafqc,task_subcomment,Fixed in gerrit 37945.,Fixed in gerrit 37945.,NA,NA,NA,NA,NA,TRUE,c1,0,TRUE,NA,-29,NA,['Fixed in gerrit 37945.'],NA,0,Fixed in gerrit 37945.,TASK PROGRESS,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?).,OBSERVED BUG BEHAVIOR,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Firefox - Detected script lockup.,BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Misplacing a bulleted / numbered list can cause a script lockup.,BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Tested on both Firefox 22 and Chrome 28\n\nSteps to reproduce:\n- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.,BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"- Click the ""Lauda Air Flight 004"" infobox and make sure it remains selected.",BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"- Click the ""Bulleted List"" button.",BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,A list bullet is added to the article.,OBSERVED BUG BEHAVIOR,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,- Click right after the bullet that was just inserted.,BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"Now click the ""Bulleted list"" button again.",BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Normally this would remove the bullet again.,EXPECTED BEHAVIOR,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Instead of that both Firefox and Chrome seem to lock up.,OBSERVED BUG BEHAVIOR,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed.,OBSERVED BUG BEHAVIOR,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,Cancelling the script allows you to regain browser control.,WORKAROUND,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,"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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.",BUG REPRODUCTION,, 3202,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}",1374695580,PHID-USER-ohetl546bwt5ac2szu5w,PHID-TASK-ph24e22ltq2s3oztatem,task_description,"VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}","VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?)./n/nFirefox - 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}",High,80,1383848723,NA,resolved,TRUE,c1,3,FALSE,FALSE,3,NA,"['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\n\nSteps to reproduce:\n- 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)\n\nIn practice one would never want to add a bulleted list this way, but actually ""crashing"" makes it severe enough to report i would assume.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897}']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11897},OBSERVED BUG BEHAVIOR,, 3203,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.",1383848723,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ph24e22ltq2s3oztatem,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,18,NA,"['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.']",NA,0,"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.",ACTION ON ISSUE,, 3204,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",1383813525,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ph24e22ltq2s3oztatem,task_subcomment,"(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","(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",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.,INVESTIGATION AND EXPLORATION,, 3204,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",1383813525,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ph24e22ltq2s3oztatem,task_subcomment,"(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","(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",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".",ISSUE CONTENT MANAGEMENT,, 3204,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",1383813525,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ph24e22ltq2s3oztatem,task_subcomment,"(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","(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",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,"QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.",ACTION ON ISSUE,, 3204,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",1383813525,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ph24e22ltq2s3oztatem,task_subcomment,"(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","(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",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,18,NA,"['(In reply to comment #3)\nQUOTE\n\nPlease ALWAYS provide version information for browsers.', 'Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".', 'QUOTE\n\nNo identifiable code commit, hence changing to WORKSFORME instead of FIXED.', 'Also see URL']",NA,0,Also see URL,INVESTIGATION AND EXPLORATION,, 3205,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.",1383785800,PHID-USER-24djtv3gj5gua2y6u2g5,PHID-TASK-ph24e22ltq2s3oztatem,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['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.']",NA,0,Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.,BUG REPRODUCTION,, 3205,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.",1383785800,PHID-USER-24djtv3gj5gua2y6u2g5,PHID-TASK-ph24e22ltq2s3oztatem,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.","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.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['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.']",NA,0,"If you can still reproduce it ,please reopen the bug.",ACTION ON ISSUE,, 3206,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 (?),1380836632,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ph24e22ltq2s3oztatem,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 (?),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 (?),NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,['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 (?)'],NA,0,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 (?),OBSERVED BUG BEHAVIOR,, 3207,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.,1380534678,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-ph24e22ltq2s3oztatem,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.,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.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"[""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.']",NA,0,Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.,ACTION ON ISSUE,, 3207,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.,1380534678,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-ph24e22ltq2s3oztatem,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.,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.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"[""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.']",NA,0,We should have a 'crash' or 'dataloss' keyword.,ISSUE CONTENT MANAGEMENT,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Note that this is not the same as bug 50715.,ISSUE CONTENT MANAGEMENT,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.",ISSUE CONTENT MANAGEMENT,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,e.g.,NA,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.",INVESTIGATION AND EXPLORATION,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Having added ""mw.log(\",NA,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,", name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).",INVESTIGATION AND EXPLORATION,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Also weird that the callback is constantly triggered twice, once for null and once for the actual value.",INVESTIGATION AND EXPLORATION,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.",SOLUTION DISCUSSION,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 3860,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",1372913640,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_description,"VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""1"", ""2""] > addParameterSearch-select ""user"" [""1"", ""2""] > ""Add"" is enabled case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select 1 [""date"", ""user""] > ""Add"" is enabled typing ""user"" > addParameterSearch-select null [""date"", ""user""] > addParameterSearch-select null [""date"", ""user""] > ""Add"" is disabled The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added./n/nNote that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play. e.g. given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively. Having added ""mw.log('addParameterSearch-select', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations: case {{Unsigned|Foo|April 1}} case {{Unsigned|1=Foo|2=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE case {{Unsigned|user=Foo|timestamp=April 1}} typing ""1"" QUOTE QUOTE QUOTE typing ""user"" QUOTE QUOTE QUOTE The latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?). Also weird that the callback is constantly triggered twice, once for null and once for the actual value. Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1373497400,NA,resolved,TRUE,c1,3,TRUE,FALSE,0,NA,"[""VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added."", 'Note that this is not the same as bug 50715.', 'Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.', 'e.g.', 'given our Unsigned template with parameter ""user"", ""timestamp"" and aliases ""1"" and ""2"" respectively.', 'Having added ""mw.log(\'addParameterSearch-select\', name, names);"" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:\n\n case {{Unsigned|Foo|April 1}}\n case {{Unsigned|1=Foo|2=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\n case {{Unsigned|user=Foo|timestamp=April 1}}\n typing ""1""\nQUOTE\nQUOTE\nQUOTE\n typing ""user""\nQUOTE\nQUOTE\nQUOTE\n\nThe latter case actually works as expected, although it is odd that the value given to the select callback is null and not ""user"" and that the button is already disabled (probably by the select widget?).', 'Also weird that the callback is constantly triggered twice, once for null and once for the actual value.', 'Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added.,OBSERVED BUG BEHAVIOR,, 3861,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,1373497400,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-xwzbnkc2eempknw62ukj,task_subcomment,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['This is now fixed in master and we will push to production very soon.', 'Sorry for the inconvenience.']",NA,0,This is now fixed in master and we will push to production very soon.,TASK PROGRESS,, 3861,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,1373497400,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-xwzbnkc2eempknw62ukj,task_subcomment,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['This is now fixed in master and we will push to production very soon.', 'Sorry for the inconvenience.']",NA,0,Sorry for the inconvenience.,SOCIAL CONVERSATION,, 3862,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010",1373497076,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xwzbnkc2eempknw62ukj,task_subcomment,"Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010","Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['Change 73010 merged by jenkins-bot:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL'],NA,0,Change 73010 merged by jenkins-bot:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL,TASK PROGRESS,, 3863,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,"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",1373483212,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xwzbnkc2eempknw62ukj,task_subcomment,"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","Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['Change 73010 had a related patch set uploaded by Trevor Parscal:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL'],NA,0,Change 73010 had a related patch set uploaded by Trevor Parscal:\nRetain original param names and ignore leading/trailing whitespace\n\nGERRIT_URL,TASK PROGRESS,, 3864,VisualEditor: Transclusion dialog doesn't account for aliases when preventing duplicate entries from being added,Working on this.,1372913735,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-xwzbnkc2eempknw62ukj,task_subcomment,Working on this.,Working on this.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,0,NA,['Working on this.'],NA,0,Working on this.,CONTRIBUTION AND COMMITMENT,, 4103,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",1372554600,PHID-USER-2mkpm2voxepwvz7abjug,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_description,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",High,80,1384200108,NA,resolved,TRUE,c1,2,FALSE,FALSE,-1,NA,"[""VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog."", 'After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal",OBSERVED BUG BEHAVIOR,, 4103,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",1372554600,PHID-USER-2mkpm2voxepwvz7abjug,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_description,"VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog./n/nAfter having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template test I made on beta was {{test|name = hello}} -------------------------- **Version**: unspecified **Severity**: normal",High,80,1384200108,NA,resolved,TRUE,c1,2,FALSE,FALSE,-1,NA,"[""VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog."", 'After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template\n\ntest I made on beta was {{test|name = hello}}\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog.,OBSERVED BUG BEHAVIOR,, 4104,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",1384200108,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,19,NA,"['Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such.', 'Please re-open if it recurs.']",NA,0,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such.",TASK PROGRESS,, 4104,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",1384200108,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.","Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,19,NA,"['Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such.', 'Please re-open if it recurs.']",NA,0,Please re-open if it recurs.,ACTION ON ISSUE,, 4105,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,Can't reproduce this bug.,1384198743,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,Can't reproduce this bug.,Can't reproduce this bug.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,19,NA,"[""Can't reproduce this bug.""]",NA,0,Can't reproduce this bug.,BUG REPRODUCTION,, 4106,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"When I make a new template entry and open the template before I've saved the page, it looks like following: http://i.imgur.com/HxaU7F1.png But after having saved the page, and enter template edit again, I'm getting following: http://i.imgur.com/VPROUwb.png",1372596044,PHID-USER-2mkpm2voxepwvz7abjug,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"When I make a new template entry and open the template before I've saved the page, it looks like following: http://i.imgur.com/HxaU7F1.png But after having saved the page, and enter template edit again, I'm getting following: http://i.imgur.com/VPROUwb.png","When I make a new template entry and open the template before I've saved the page, it looks like following: URL But after having saved the page, and enter template edit again, I'm getting following: URL",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-1,NA,"[""When I make a new template entry and open the template before I've saved the page, it looks like following:\nURL\n\nBut after having saved the page, and enter template edit again, I'm getting following:\nURL""]",NA,0,"When I make a new template entry and open the template before I've saved the page, it looks like following:\nURL\n\nBut after having saved the page, and enter template edit again, I'm getting following:\nURL",BUG REPRODUCTION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,"(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?",INVESTIGATION AND EXPLORATION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?,INVESTIGATION AND EXPLORATION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,What does that mean?,SOCIAL CONVERSATION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,You say it is visible for the template but not for the parameters.,INVESTIGATION AND EXPLORATION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,So what is visible then?,INVESTIGATION AND EXPLORATION,, 4107,VisualEditor: TemplateData hints doesn't show up on parameters in transclusion dialog,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?",1372557963,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-ey46lj4dpzgt5ypwdhi4,task_subcomment,"(In reply to comment #0) > After having saved a template on a page By a template, you mean a template transclusion or the template itself? > and edit it again, template data for > the template is visible, but any parameter used is not showing templatedata, So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? > even though it displayed it correctly when I created the template Displayed what?","(In reply to comment #0) QUOTE By a template, you mean a template transclusion or the template itself? QUOTE QUOTE So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean? You say it is visible for the template but not for the parameters. So what is visible then? QUOTE Displayed what?",NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['(In reply to comment #0)\nQUOTE\n\nBy a template, you mean a template transclusion or the template itself?', 'QUOTE\nQUOTE\n\nSo when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters?', 'What does that mean?', 'You say it is visible for the template but not for the parameters.', 'So what is visible then?', 'QUOTE\n\nDisplayed what?']",NA,0,QUOTE\n\nDisplayed what?,SOCIAL CONVERSATION,, 4439,VisualEditor: Preserve ordering inside data-mw elements,"Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_description,"VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",High,80,1372039643,NA,resolved,TRUE,c1,2,TRUE,FALSE,-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,VisualEditor: Preserve ordering inside data-mw elements.,SOLUTION USAGE,, 4439,VisualEditor: Preserve ordering inside data-mw elements,"Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_description,"VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",High,80,1372039643,NA,resolved,TRUE,c1,2,TRUE,FALSE,-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 4439,VisualEditor: Preserve ordering inside data-mw elements,"Currently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",1372028700,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_description,"VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major","VisualEditor: Preserve ordering inside data-mw elements./n/nCurrently we don't and cause major headaches for Parsoid. -------------------------- **Version**: unspecified **Severity**: major",High,80,1372039643,NA,resolved,TRUE,c1,2,TRUE,FALSE,-2,NA,"['VisualEditor: Preserve ordering inside data-mw elements.', ""Currently we don't and cause major headaches for Parsoid."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,Currently we don't and cause major headaches for Parsoid.,OBSERVED BUG BEHAVIOR,, 4440,VisualEditor: Preserve ordering inside data-mw elements,"**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up",1373983343,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,"**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,2,NA,"['**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug.', 'However, that bug is still showing up: URL']",NA,0,**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4440,VisualEditor: Preserve ordering inside data-mw elements,"**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up",1373983343,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,"**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up","**ignatzmice.wiki** wrote: Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,2,NA,"['**ignatzmice.wiki** wrote:\n\nApparently bug 50080 is a duplicate of this bug.', 'However, that bug is still showing up: URL']",NA,0,"However, that bug is still showing up: URL",OBSERVED BUG BEHAVIOR,, 4441,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50108 has been marked as a duplicate of this bug. ***,1372101714,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50108 has been marked as a duplicate of this bug. ***,*** Bug 50108 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50108 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4441,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50108 has been marked as a duplicate of this bug. ***,1372101714,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50108 has been marked as a duplicate of this bug. ***,*** Bug 50108 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4442,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50108 has been marked as a duplicate of this bug. ***,1372091701,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50108 has been marked as a duplicate of this bug. ***,*** Bug 50108 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50108 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4442,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50108 has been marked as a duplicate of this bug. ***,1372091701,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50108 has been marked as a duplicate of this bug. ***,*** Bug 50108 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50108 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4443,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50106 has been marked as a duplicate of this bug. ***,1372091672,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50106 has been marked as a duplicate of this bug. ***,*** Bug 50106 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50106 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50106 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4443,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50106 has been marked as a duplicate of this bug. ***,1372091672,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50106 has been marked as a duplicate of this bug. ***,*** Bug 50106 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50106 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4444,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50101 has been marked as a duplicate of this bug. ***,1372091521,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50101 has been marked as a duplicate of this bug. ***,*** Bug 50101 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50101 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50101 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4444,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50101 has been marked as a duplicate of this bug. ***,1372091521,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50101 has been marked as a duplicate of this bug. ***,*** Bug 50101 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50101 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4445,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50099 has been marked as a duplicate of this bug. ***,1372091385,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50099 has been marked as a duplicate of this bug. ***,*** Bug 50099 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50099 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50099 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4445,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50099 has been marked as a duplicate of this bug. ***,1372091385,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50099 has been marked as a duplicate of this bug. ***,*** Bug 50099 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50099 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4446,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50080 has been marked as a duplicate of this bug. ***,1372039230,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50080 has been marked as a duplicate of this bug. ***,*** Bug 50080 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50080 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 50080 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 4446,VisualEditor: Preserve ordering inside data-mw elements,*** Bug 50080 has been marked as a duplicate of this bug. ***,1372039230,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,*** Bug 50080 has been marked as a duplicate of this bug. ***,*** Bug 50080 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,2,TRUE,NA,-1,NA,"['*** Bug 50080 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 4447,VisualEditor: Preserve ordering inside data-mw elements,Related URL: https://gerrit.wikimedia.org/r/70109 (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff),1372032121,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-spoxch2h3fjmkmu6pdme,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/70109 (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff),Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff),NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-1,NA,['Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)'],NA,0,Related URL: GERRIT_URL (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff),INVESTIGATION AND EXPLORATION,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,VisualEditor: Transclusion editor broken in IE10 (stack overflow).,OBSERVED BUG BEHAVIOR,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In IE10, any attempt to open the transclusion editor leads to a stack overflow.",OBSERVED BUG BEHAVIOR,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.",INVESTIGATION AND EXPLORATION,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n\nSCRIPT5: Access is denied.",INVESTIGATION AND EXPLORATION,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n\nSCRIPT5: Access is denied.",INVESTIGATION AND EXPLORATION,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.",INVESTIGATION AND EXPLORATION,, 4487,VisualEditor: Transclusion editor broken in IE10 (stack overflow),"In IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",1371982020,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_description,"VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Transclusion editor broken in IE10 (stack overflow)./n/nIn IE10, any attempt to open the transclusion editor leads to a stack overflow. In the dev console I get this: --- SCRIPT28: Out of stack space load.php, line 46 character 700 [this location is different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 SCRIPT5: Access is denied. load.php, line 305 character 273 [... ad infinitum] SCRIPT2343: Stack overflow at line: 46 [different every time] SCRIPT5: Access is denied. load.php, line 305 character 273 --- -------------------------- **Version**: unspecified **Severity**: normal",High,80,1409958003,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: Transclusion editor broken in IE10 (stack overflow).', 'In IE10, any attempt to open the transclusion editor leads to a stack overflow.', 'In the dev console I get this:\n\n--- \nSCRIPT28: Out of stack space \nload.php, line 46 character 700 [this location is different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273 \n[... ad infinitum]\n\nSCRIPT2343: Stack overflow at line: 46 [different every time]\n\nSCRIPT5: Access is denied.', 'load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"load.php, line 305 character 273\n---\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal",OBSERVED BUG BEHAVIOR,, 4488,VisualEditor: Transclusion editor broken in IE10 (stack overflow),This doesn't happen in IE10 with master.,1409958003,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-2go6ew7f46vsl6ngyy7w,task_subcomment,This doesn't happen in IE10 with master.,This doesn't happen in IE10 with master.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"[""This doesn't happen in IE10 with master.""]",NA,0,This doesn't happen in IE10 with master.,BUG REPRODUCTION,, 5553,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,"e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_description,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366927098,NA,resolved,TRUE,c1,1,TRUE,FALSE,-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in\n\n<p>a</p><p>c</p><p></p><p>d</p><p>b</p>\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.,OBSERVED BUG BEHAVIOR,, 5553,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,"e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_description,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366927098,NA,resolved,TRUE,c1,1,TRUE,FALSE,-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in\n\n<p>a</p><p>c</p><p></p><p>d</p><p>b</p>\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,e.g.,NA,, 5553,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,"e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_description,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366927098,NA,resolved,TRUE,c1,1,TRUE,FALSE,-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in\n\n<p>a</p><p>c</p><p></p><p>d</p><p>b</p>\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in\n\n<p>a</p><p>c</p><p></p><p>d</p><p>b</p>\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.",OBSERVED BUG BEHAVIOR,, 5553,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,"e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",1364923620,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_description,"VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph./n/ne.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in <p>a</p><p>c</p><p></p><p>d</p><p>b</p> This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1366927098,NA,resolved,TRUE,c1,1,TRUE,FALSE,-13,NA,"['VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph.', 'e.g.', 'inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in\n\n<p>a</p><p>c</p><p></p><p>d</p><p>b</p>\n\nThis is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 5554,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,NB: this bug is not restricted to paragraphs,1364923756,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_subcomment,NB: this bug is not restricted to paragraphs,NB: this bug is not restricted to paragraphs,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-13,NA,['NB: this bug is not restricted to paragraphs'],NA,0,NB: this bug is not restricted to paragraphs,OBSERVED BUG BEHAVIOR,, 5555,VisualEditor: Inserting two paragraphs inside another paragraph results in the original paragraphs being separated by a blank paragraph,https://gerrit.wikimedia.org/r/#/c/55791/,1364923669,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-yqzsqc62wfjcfr3spvjk,task_subcomment,https://gerrit.wikimedia.org/r/#/c/55791/,URL,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-13,NA,['URL'],NA,0,URL,NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.,OBSERVED BUG BEHAVIOR,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.",OBSERVED BUG BEHAVIOR,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,"Showing the diff now shows the addition of ""\",NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,\,NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,\,NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,""" (either above or below the {{infobox}}, doesn\",NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,Review and save,NA,, 5761,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"Screenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",1355443440,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_description,"VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on https://en.wikipedia.org/wiki/Buri_Ram_Airport * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor Steps to reproduce problem: * Open VisualEditor on URL * The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded) * Type ""a"" Expected result: The character is inserted. Showing the diff now shows the addition of ""'''a'''"" (either above or below the {{infobox}}, doesn't really matter). Preferably below so that it is next to the paragraph it was added before. Actual result: The character is inserted. Visually nothing else changed (the infobox and the rest of the article are stil there). However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""'''a'''"" was added in its place. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F9591}",High,80,1371063971,NA,resolved,TRUE,c1,1,TRUE,FALSE,-29,NA,"['VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article.', 'Screenshot showing the diff and the editor\n\nSteps to reproduce problem:\n* Open VisualEditor on URL\n* The cursor will be on top of the article in a paragraph-placeholder with bold styling (because the first word of the article is bolded)\n* Type ""a""\n\nExpected result:\nThe character is inserted.', 'Showing the diff now shows the addition of ""\'\'\'a\'\'\'"" (either above or below the {{infobox}}, doesn\'t really matter).', 'Preferably below so that it is next to the paragraph it was added before.', 'Actual result:\nThe character is inserted.', 'Visually nothing else changed (the infobox and the rest of the article are stil there).', 'However, clicking ""Review and save"" now will show a diff where the infobox and the entire article have been removed and ""\'\'\'a\'\'\'"" was added in its place.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F9591}']",TRUE,0,\'\'\'a\'\'\',NA,, 5762,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,This seems to be fixed already (try to reproduce on English Wikipedia).,1371063948,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,This seems to be fixed already (try to reproduce on English Wikipedia).,This seems to be fixed already (try to reproduce on English Wikipedia).,NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-3,NA,['This seems to be fixed already (try to reproduce on English Wikipedia).'],NA,0,This seems to be fixed already (try to reproduce on English Wikipedia).,TASK PROGRESS,, 5763,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,I think I know what's the reason of this problem. I will work on it next week.,1364152745,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,I think I know what's the reason of this problem. I will work on it next week.,I think I know what's the reason of this problem. I will work on it next week.,NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-15,NA,"[""I think I know what's the reason of this problem."", 'I will work on it next week.']",NA,0,I will work on it next week.,CONTRIBUTION AND COMMITMENT,, 5763,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,I think I know what's the reason of this problem. I will work on it next week.,1364152745,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,I think I know what's the reason of this problem. I will work on it next week.,I think I know what's the reason of this problem. I will work on it next week.,NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-15,NA,"[""I think I know what's the reason of this problem."", 'I will work on it next week.']",NA,0,I think I know what's the reason of this problem.,INVESTIGATION AND EXPLORATION,, 5764,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,*** Bug 46506 has been marked as a duplicate of this bug. ***,1364127463,PHID-USER-qmcrs2npimuywblubznv,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,*** Bug 46506 has been marked as a duplicate of this bug. ***,*** Bug 46506 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-15,NA,"['*** Bug 46506 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 46506 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 5764,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,*** Bug 46506 has been marked as a duplicate of this bug. ***,1364127463,PHID-USER-qmcrs2npimuywblubznv,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,*** Bug 46506 has been marked as a duplicate of this bug. ***,*** Bug 46506 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-15,NA,"['*** Bug 46506 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 5765,VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article,"This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.",1357598884,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-2hzsnhrqn3e44r3w5wpx,task_subcomment,"This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.","This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-25,NA,"['This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.']",NA,0,"This is fundamentally an ""editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate"" - assigning to CE, but we really need to talk about this and what we should do longer-term.",POTENTIAL NEW ISSUES AND REQUESTS,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,VisualEditor: Trivial way to get a lot of errors.,OBSERVED BUG BEHAVIOR,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,1,NA,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Go to URL and click edit\n2.,BUG REPRODUCTION,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Select all using Ctrl-A (or Cmd-A) and press backspace\n3.,BUG REPRODUCTION,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Press any content key (e.g.,BUG REPRODUCTION,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.",OBSERVED BUG BEHAVIOR,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\",OBSERVED BUG BEHAVIOR,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,);this.parent...,NA,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Etc.,NA,, 5913,VisualEditor: Trivial way to get a lot of errors,"1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",1353120840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_description,"VisualEditor: Trivial way to get a lot of errors./n/n1. Go to https://www.mediawiki.org/wiki/VisualEditor:Testy and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical","VisualEditor: Trivial way to get a lot of errors./n/n1. Go to URL and click edit 2. Select all using Ctrl-A (or Cmd-A) and press backspace 3. Press any content key (e.g. ""a"") What should happen: : You get a document with an ""a"" in its own paragraph. What does happen: : You get a document with an ""a"" in its own paragraph, and two console errors: TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) TypeError: this.data[offset] is undefined ...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota... load.p...4105Z&* (line 89) Thereafter, pressing return in the new context gives: TypeError: node is null ...ve.Node.call(this,type);this.model=model;this.$=$element||$('<div>');this.parent... Etc. -------------------------- **Version**: unspecified **Severity**: critical",High,80,1353541840,NA,resolved,TRUE,c1,0,TRUE,FALSE,-33,NA,"['VisualEditor: Trivial way to get a lot of errors.', '1.', 'Go to URL and click edit\n2.', 'Select all using Ctrl-A (or Cmd-A) and press backspace\n3.', 'Press any content key (e.g.', '""a"")\n\nWhat should happen:\n\n: You get a document with an ""a"" in its own paragraph.', 'What does happen:\n\n: You get a document with an ""a"" in its own paragraph, and two console errors:\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nTypeError: this.data[offset] is undefined\n\n...ation)===false){return null;}while(start>0){start--;if(this.offsetContainsAnnota...\n\nload.p...4105Z&* (line 89)\n\n\nThereafter, pressing return in the new context gives:\n\nTypeError: node is null\n\n...ve.Node.call(this,type);this.model=model;this.$=$element||$(\'<div>\');this.parent...', 'Etc.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: critical,OBSERVED BUG BEHAVIOR,, 5914,VisualEditor: Trivial way to get a lot of errors,"Confirmed fixed, will be pushed live on Monday.",1353541840,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"Confirmed fixed, will be pushed live on Monday.","Confirmed fixed, will be pushed live on Monday.",NA,NA,NA,NA,NA,TRUE,c1,0,TRUE,NA,-32,NA,"['Confirmed fixed, will be pushed live on Monday.']",NA,0,"Confirmed fixed, will be pushed live on Monday.",TASK PROGRESS,, 5915,VisualEditor: Trivial way to get a lot of errors,https://gerrit.wikimedia.org/r/#/c/34597/1,1353535425,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,https://gerrit.wikimedia.org/r/#/c/34597/1,URL,NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,['URL'],NA,0,URL,NA,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"There were actually two cases, with two different root causes.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,This was fixed a while ago.,TASK PROGRESS,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"Instead, all nodes would be removed except the last paragraph, which gets stripped.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"So after removing ""everything"", we are left with a document that only contains an empty paragraph.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.,INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().",INVESTIGATION AND EXPLORATION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,Trevor has a commit queued up that will fix this.,CONTRIBUTION AND COMMITMENT,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied.",BUG REPRODUCTION,, 5916,VisualEditor: Trivial way to get a lot of errors,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",1353530127,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.","There were actually two cases, with two different root causes. If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0. This was fixed a while ago. If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied. Instead, all nodes would be removed except the last paragraph, which gets stripped. So after removing ""everything"", we are left with a document that only contains an empty paragraph. However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one). Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph. The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly. The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone. This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations(). When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage. Trevor has a commit queued up that will fix this.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-32,NA,"['There were actually two cases, with two different root causes.', 'If the last node in the document was not a paragraph, comment #2 applies: the document is empty and the pre-annotations code was asking for annotations at offset 0.', 'This was fixed a while ago.', ""If the last node in the document was a paragraph (this is common), the document wouldn't actually be emptied."", 'Instead, all nodes would be removed except the last paragraph, which gets stripped.', 'So after removing ""everything"", we are left with a document that only contains an empty paragraph.', 'However, in the model tree, this empty paragraph is truly empty and does not contain a zero-length text node (most other empty paragraphs do have one).', 'Once you type a character, CE pawns it first, processing a transaction that inserts a pawn in the paragraph.', 'The transaction processor gets confused by the lack of any content nodes in the paragraph, and issues a rebuild for the contents of the paragraph, which fails spectacularly.', 'The model tree ends up in an inconsistent state with a text node being a direct child of the document node and the paragraph node being gone.', 'This then caused offset computations to be off by one, which caused other parts of CE to do strange things, culminating in an exception in openAnnotations().', ""When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage."", 'Trevor has a commit queued up that will fix this.']",NA,0,"When the exception occurs, the pawn hasn't been unpawned yet, so there's pawn leakage.",INVESTIGATION AND EXPLORATION,, 5917,VisualEditor: Trivial way to get a lot of errors,"After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",1353138590,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-33,NA,"[""After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails."", 'Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists.']",NA,0,Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists.,SOLUTION DISCUSSION ,, 5917,VisualEditor: Trivial way to get a lot of errors,"After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",1353138590,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,"After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.","After deleting all the content document if completely empty (data.length = 0), however view still askes what are the annotations at offset 0 - and that's what fails. Possible fix it to make method getAnnotationsFromOffset return empty set if given offset does not exists.",NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-33,NA,"[""After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails."", 'Possible fix it to make method getAnnotationsFromOffset return empty set if\ngiven offset does not exists.']",NA,0,"After deleting all the content document if completely empty (data.length = 0),\nhowever view still askes what are the annotations at offset 0 - and that's what\nfails.",INVESTIGATION AND EXPLORATION,, 5918,VisualEditor: Trivial way to get a lot of errors,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,1353138404,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-33,NA,"['%%%*** Bug 42218 has been marked as a duplicate of this bug.', '***%%%']",NA,0,%%%*** Bug 42218 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 5918,VisualEditor: Trivial way to get a lot of errors,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,1353138404,PHID-USER-s7sn3zjthnxvep34c5ho,PHID-TASK-vsfkgcc5kyalos6vc4gl,task_subcomment,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,%%%*** Bug 42218 has been marked as a duplicate of this bug. ***%%%,NA,NA,NA,NA,NA,TRUE,c1,0,FALSE,NA,-33,NA,"['%%%*** Bug 42218 has been marked as a duplicate of this bug.', '***%%%']",NA,0,***%%%,NA,, 6124,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_description,"Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL",Medium,50,1382549565,NA,resolved,TRUE,c1,3,FALSE,FALSE,12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,Bugzilla data scanned for tech metrics must be aligned with repos scanned.,EXPECTED BEHAVIOR,, 6124,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_description,"Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL",Medium,50,1382549565,NA,resolved,TRUE,c1,3,FALSE,FALSE,12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.",OBSERVED BUG BEHAVIOR,, 6124,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_description,"Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL",Medium,50,1382549565,NA,resolved,TRUE,c1,3,FALSE,FALSE,12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"A 100% match is probably impossible, but a 90% (or so) should be feasible.",EXPECTED BEHAVIOR,, 6124,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_description,"Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL",Medium,50,1382549565,NA,resolved,TRUE,c1,3,FALSE,FALSE,12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 6124,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Currently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744",1379952300,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_description,"Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently http://korma.wmflabs.org/browser/its-repos.html shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with http://korma.wmflabs.org/browser/scm-repos.html - which in turn is synced with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=49744","Bugzilla data scanned for tech metrics must be aligned with repos scanned./n/nCurrently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid. However, this list must be in sync with URL - which in turn is synced with URL Let's update that wiki page with the relevant products / components. A 100% match is probably impossible, but a 90% (or so) should be feasible. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL",Medium,50,1382549565,NA,resolved,TRUE,c1,3,FALSE,FALSE,12,NA,"['Bugzilla data scanned for tech metrics must be aligned with repos scanned.', 'Currently URL shows that the Bugzilla products scanned are MediaWiki, All extensions, VisualEditor and Parsoid.', ""However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components."", 'A 100% match is probably impossible, but a 90% (or so) should be feasible.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",FALSE,0,"However, this list must be in sync with URL - which in turn is synced with URL\n\nLet's update that wiki page with the relevant products / components.",SOLUTION DISCUSSION,, 6125,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.,INVESTIGATION AND EXPLORATION,, 6125,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.",MOTIVATION,, 6125,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,"* Treating each component separately, just like we do with code repos.",EXPECTED BEHAVIOR,, 6125,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time",1382560830,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"(In reply to comment #6) > ==Core Extensions== > Don't want to spend too much time going through the list and syncing with > https://bugzilla.wikimedia.org/editcomponents. > cgi?product=MediaWiki%20extensions > however noteworthy naming differences from the top of my head: Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] https://www.mediawiki.org/wiki/Community_metrics#Bugzilla_response_time","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE Currently korma lists all the extensions in a single project. This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise: * Including only the key projects. * Treating each component separately, just like we do with code repos. [1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nCurrently korma lists all the extensions in a single project.', 'This is good enough for now, but for the Bugzilla Response Time KPI [1] we will need to be more precise:\n\n* Including only the key projects.', '* Treating each component separately, just like we do with code repos.', '[1] URL']",NA,0,[1] URL,NA,, 6126,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Ok guys, you have the viz in: http://korma.wmflabs.org/browser/its-repos.html",1382549565,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Ok guys, you have the viz in: http://korma.wmflabs.org/browser/its-repos.html","Ok guys, you have the viz in: URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['Ok guys, you have the viz in:\n\nURL']",NA,0,"Ok guys, you have the viz in:\n\nURL",SOLUTION DISCUSSION,, 6127,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,"Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.",SOLUTION DISCUSSION,, 6127,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.,NA,, 6127,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.",1382519999,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Great, I have programmed for adding to the report the next repos: Analytics > Kraken: https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=kraken&list_id=243545 Datasets > Webstatscollector: https://bugzilla.wikimedia.org/buglist.cgi?product=datasets&component=Webstatscollector&list_id=243568 Analytics > Wikimetrics https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikimetrics Analytics > Wikistats https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=wikistats Analytics > Limn https://bugzilla.wikimedia.org/buglist.cgi?product=analytics&component=limn Analytics > General/Unknown https://bugzilla.wikimedia.org/buglist.cgi?product=Analytics&component=General%2FUnknown Commons App > iOS (iPhone or iPad) https://bugzilla.wikimedia.org/buglist.cgi?product=Commons%20App&component=iOS%20%28iPhone%20or%20iPad%29 Wikipedia App https://bugzilla.wikimedia.org/buglist.cgi?product=wikipedia%20app Wiki Loves Monuments > Mobile https://bugzilla.wikimedia.org/buglist.cgi?product=Wiki%20Loves%20Monuments&component=Mobile Wikimedia > Continuous integration https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Continuous%20integration Wikimedia > DNS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=dns Wikimedia > OTRS https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=otrs Wikimedia > Bugzilla https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=bugzilla Wikimedia > wikibugs IRC bot https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=wikibugs%20IRC%20bot Wikimedia > Blog https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=blog Wikimedia > Fundraising: Misc. https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Misc. Wikimedia > Fundraising: Requirements https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=Fundraising%3A%20Requirements Tools > code-utils https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=code-utils Tools > mw-dumper https://bugzilla.wikimedia.org/buglist.cgi?product=tools&component=mwdumper Pywikibot > * https://bugzilla.wikimedia.org/buglist.cgi?product=Pywikibot MediaWiki-Vagrant > * https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki-Vagrant Wikimedia Labs > tools https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia%20labs&component=tools openZIM > * https://bugzilla.wikimedia.org/buglist.cgi?product=openZIM Wikimedia > Quality Assurance https://bugzilla.wikimedia.org/buglist.cgi?product=wikimedia&component=quality%20assurance I have checked all of them and works. So tomorrow you should have the new info.","Great, I have programmed for adding to the report the next repos: Analytics > Kraken: URL Datasets > Webstatscollector: URL Analytics > Wikimetrics URL Analytics > Wikistats URL Analytics > Limn URL Analytics > General/Unknown URL Commons App > iOS (iPhone or iPad) URL Wikipedia App URL Wiki Loves Monuments > Mobile URL Wikimedia > Continuous integration URL Wikimedia > DNS URL Wikimedia > OTRS URL Wikimedia > Bugzilla URL Wikimedia > wikibugs IRC bot URL Wikimedia > Blog URL Wikimedia > Fundraising: Misc. URL Wikimedia > Fundraising: Requirements URL Tools > code-utils URL Tools > mw-dumper URL Pywikibot > * URL MediaWiki-Vagrant > * URL Wikimedia Labs > tools URL openZIM > * URL Wikimedia > Quality Assurance URL I have checked all of them and works. So tomorrow you should have the new info.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['Great, I have programmed for adding to the report the next repos:\n\nAnalytics > Kraken: URL\nDatasets > Webstatscollector: URL\nAnalytics > Wikimetrics URL\nAnalytics > Wikistats URL\nAnalytics > Limn URL\nAnalytics > General/Unknown URL\nCommons App > iOS (iPhone or iPad) URL\nWikipedia App URL\nWiki Loves Monuments > Mobile URL\nWikimedia > Continuous integration URL\nWikimedia > DNS URL\nWikimedia > OTRS URL\nWikimedia > Bugzilla URL\nWikimedia > wikibugs IRC bot URL\nWikimedia > Blog URL\nWikimedia > Fundraising: Misc.', 'URL\nWikimedia > Fundraising: Requirements URL\nTools > code-utils URL\nTools > mw-dumper URL\nPywikibot > * URL\nMediaWiki-Vagrant > * URL\nWikimedia Labs > tools URL\nopenZIM > * URL\nWikimedia > Quality Assurance URL\n\nI have checked all of them and works.', 'So tomorrow you should have the new info.']",NA,0,So tomorrow you should have the new info.,FUTURE PLANS,, 6128,Bugzilla data scanned for tech metrics must be aligned with repos scanned,Yes!,1382370607,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,Yes!,Yes!,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,['Yes!'],NA,0,Yes!,SOCIAL CONVERSATION,, 6129,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?",1382353678,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?","Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,"['Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?']",NA,0,"Ok guys, is this ready to start downloading all those bugzilla product and components and adding them to the korma browser?",CONTRIBUTION AND COMMITMENT,, 6130,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.",SOLUTION DISCUSSION,, 6130,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,"I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".",SOLUTION DISCUSSION,, 6130,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.,NA,, 6130,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",1382025323,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with https://bugzilla.wikimedia.org/editcomponents.cgi?product=MediaWiki%20extensions however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo","I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1. I just hope to avoid n:n. :) [[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component ==Analytics== analytics/kraken -- Analytics > Kraken analytics/webstatscollector -- Datasets > Webstatscollector analytics/wikimetrics -- Analytics > Wikimetrics analytics/wikistats -- Analytics > Wikistats github.com/wikimedia/limn -- Analytics > Limn analytics/* -- Analytics > General/Unknown ==Mobile apps== apps/android/commons github.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad) github.com/wikimedia/WikipediaMobile -- Wikipedia App github.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App github.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile ==Integration== * -- Wikimedia > Continuous integration ==Operations== Hard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"". operations/dns -- Wikimedia > DNS operations/software/otrs -- Wikimedia > OTRS ==Wikimedia== ====Bugzilla==== wikimedia/bugzilla/modifications -- Wikimedia > Bugzilla wikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla wikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot ====Communication==== wikimedia/communications/WMBlog -- Wikimedia > Blog ====Fundraising==== Mostly using CiviCRM; related components in Bugzilla are: -- MediaWiki extensions > FundraiserLandingPage -- MediaWiki extensions > FundraiserPortal -- Wikimedia > Fundraising Misc. -- Wikimedia > Fundraising Requirements ==MediaWiki misc== mediawiki/php/FastStringSearch mediawiki/php/NativePreprocessor mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2 mediawiki/tools/code-utils -- Tools > code-utils mediawiki/tools/mwdumper -- Tools > mw-dumper ==Pywikibot== pywikibot/* -- Pywikibot > * ==Other== mediawiki/vagrant -- MediaWiki-Vagrant > * labs/toollabs -- Wikimedia Labs > tools openzim -- openZIM > * qa/browsertests -- Wikimedia > Quality Assurance ==Core Extensions== Don't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head: PageTriage -- MediaWiki extensions > PageCuration Parsoid -- Parsoid > * SyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi) VisualEditor -- VisualEditor > * Wikibase -- MediaWiki extensions > WikidataRepo",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['I guess we all know that there are no clear 1:1 mapping is possible, but instead 1:n or n:1.', 'I just hope to avoid n:n. :)\n\n\n[[wikitech:Key_Wikimedia_software_projects]] -- Bugzilla product > component\n\n\n==Analytics==\nanalytics/kraken -- Analytics > Kraken\nanalytics/webstatscollector -- Datasets > Webstatscollector\nanalytics/wikimetrics -- Analytics > Wikimetrics\nanalytics/wikistats -- Analytics > Wikistats\ngithub.com/wikimedia/limn -- Analytics > Limn\nanalytics/* -- Analytics > General/Unknown\n==Mobile apps==\napps/android/commons \ngithub.com/wikimedia/Commons-iOS -- Commons App > iOS (iPhone or iPad)\ngithub.com/wikimedia/WikipediaMobile -- Wikipedia App\ngithub.com/wikimedia/WikipediaMobileFirefoxOS -- Wikipedia App\ngithub.com/wikimedia/WLMMobile -- Wiki Loves Monuments > Mobile\n==Integration==\n* -- Wikimedia > Continuous integration\n==Operations==\nHard to define, mostly in rt.wikimedia.org, some in Bugzilla under ""Wikimedia > General"" with keyword ""ops"".', 'operations/dns -- Wikimedia > DNS\noperations/software/otrs -- Wikimedia > OTRS\n==Wikimedia==\n====Bugzilla====\nwikimedia/bugzilla/modifications -- Wikimedia > Bugzilla\nwikimedia/bugzilla/triagescripts -- Wikimedia > Bugzilla\nwikimedia/bugzilla/wikibugs -- Wikimedia > wikibugs IRC bot\n====Communication====\nwikimedia/communications/WMBlog -- Wikimedia > Blog\n====Fundraising====\nMostly using CiviCRM; related components in Bugzilla are:\n -- MediaWiki extensions > FundraiserLandingPage\n -- MediaWiki extensions > FundraiserPortal\n -- Wikimedia > Fundraising Misc.', ""-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo""]",NA,0,-- Wikimedia > Fundraising Requirements\n==MediaWiki misc==\nmediawiki/php/FastStringSearch\n mediawiki/php/NativePreprocessor\n mediawiki/php/luasandbox -- MediaWiki extensions > Scribunto\n mediawiki/php/wikidiff2 -- MediaWiki extensions > wikidiff2\nmediawiki/tools/code-utils -- Tools > code-utils\nmediawiki/tools/mwdumper -- Tools > mw-dumper\n==Pywikibot==\npywikibot/* -- Pywikibot > *\n==Other==\nmediawiki/vagrant -- MediaWiki-Vagrant > *\nlabs/toollabs -- Wikimedia Labs > tools\nopenzim -- openZIM > *\nqa/browsertests -- Wikimedia > Quality Assurance\n==Core Extensions==\nDon't want to spend too much time going through the list and syncing with URL however noteworthy naming differences from the top of my head:\n\nPageTriage -- MediaWiki extensions > PageCuration\nParsoid -- Parsoid > *\nSyntaxHighlight_GeSHi -- MediaWiki extensions > SyntaxHighlight (GeSHi)\nVisualEditor -- VisualEditor > *\nWikibase -- MediaWiki extensions > WikidataRepo,NA,, 6131,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Andre, if you could point to the Bugzilla product/component of each project at https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects that would be perfect!",1381773164,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Andre, if you could point to the Bugzilla product/component of each project at https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects that would be perfect!","Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,15,NA,"['Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!']",NA,0,"Andre, if you could point to the Bugzilla product/component of each project at URL that would be perfect!",INVESTIGATION AND EXPLORATION,, 6132,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)",1381764843,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)","(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)']",NA,0,"(If there is something I can specifically help with as Bugzilla admin, please tell me what I need to do for you folks.)",CONTRIBUTION AND COMMITMENT,, 6133,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",1381760730,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,15,NA,"['Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?', 'Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!']",NA,0,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?",CONTRIBUTION AND COMMITMENT,, 6133,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",1381760730,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!","Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community? Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,15,NA,"['Quim, for the Bugzilla components mapping, do you have some plan in mind for gathering the info from Wikimedia Community?', 'Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!']",NA,0,"Maybe we can start doing the mapping of the more clear components, but it there is a complete process to cover all of them, much better!",CONTRIBUTION AND COMMITMENT,, 6134,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"Yes Quim, we can scan only components.",1380184604,PHID-USER-lepsd737p6wqwsowcou2,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"Yes Quim, we can scan only components.","Yes Quim, we can scan only components.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,12,NA,"['Yes Quim, we can scan only components.']",NA,0,"Yes Quim, we can scan only components.",SOLUTION DISCUSSION,, 6135,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",1379952721,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.","<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,12,NA,"['<27><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?', ""The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.""]",NA,0,"<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?",INVESTIGATION AND EXPLORATION,, 6135,Bugzilla data scanned for tech metrics must be aligned with repos scanned,"<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",1379952721,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-rmkl7hs2ktj4cx7nvrl4,task_subcomment,"<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.","<22><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product? The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,12,NA,"['<27><>lvaro, can MetricsGrimoire scan only specific components of a Bugzilla product?', ""The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.""]",NA,0,"The reason to ask is that, ideally, we wouldn't scan the whole MediaWiki Extension product but only the relevant components.",SOLUTION DISCUSSION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.,OBSERVED BUG BEHAVIOR,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.,BUG REPRODUCTION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"3)Click on Languages/cog, select Input and click on Enable Input tools.",BUG REPRODUCTION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,4)Click on Edit beta tab.,BUG REPRODUCTION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.",BUG REPRODUCTION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.",OBSERVED BUG BEHAVIOR,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.",OBSERVED BUG BEHAVIOR,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.",OBSERVED BUG BEHAVIOR,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,4)Click on Save page button\n5)Now both the images are visible again.,BUG REPRODUCTION,, 6191,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",1379529000,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_description,"VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** `renukaalurkar` **Description:** 1)Logged in to http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME./n/n**Author:** CODE **Description:** 1)Logged in to URL 2)Go to your user page. 3)Click on Languages/cog, select Input and click on Enable Input tools. 4)Click on Edit beta tab. 5)Click on More, and using Media, select a couple of pictures 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu 7)Now start entering text in Hindi or Telugu. Observations: 1)After typing a few letters, the cursor jumps back to the beginning of the sentence. 2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph. 3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears. 4)Click on Save page button 5)Now both the images are visible again. Observed on Firefox 24.0 and Chrome 29.0.1547.66 -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1453748296,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,11,NA,"['VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME.', '**Author:** CODE\n\n**Description:**\n1)Logged in to URL\n2)Go to your user page.', '3)Click on Languages/cog, select Input and click on Enable Input tools.', '4)Click on Edit beta tab.', '5)Click on More, and using Media, select a couple of pictures\n6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu\n7)Now start entering text in Hindi or Telugu.', 'Observations:\n1)After typing a few letters, the cursor jumps back to the beginning of the sentence.', '2)Sometimes, when Enter is hit, the cursor goes back to the beginning of the paragraph.', '3)Sometimes, when Enter is hit one of the images disappears.Write some more and the other image also disappears.', '4)Click on Save page button\n5)Now both the images are visible again.', 'Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,Observed on Firefox 24.0 and Chrome 29.0.1547.66\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 6192,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"As of https://gerrit.wikimedia.org/r/#/c/264577/ in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.",1453748296,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"As of https://gerrit.wikimedia.org/r/#/c/264577/ in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.","As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,134,NA,"['As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.']",NA,0,"As of URL in #jquery.ime this should now be resolved and working for all users, and will be part of the wmf.12 release starting tomorrow.",TASK PROGRESS,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,QUOTE\nQUOTE\n\nWhere exactly?,INVESTIGATION AND EXPLORATION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"In the ""alternative caption"" field of the ""Insert Image"" dialog?",INVESTIGATION AND EXPLORATION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,Some other field?,INVESTIGATION AND EXPLORATION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,The text of the page you edit?,INVESTIGATION AND EXPLORATION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,"At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.",BUG REPRODUCTION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).,BUG REPRODUCTION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,Clarification highly welcome.,INVESTIGATION AND EXPLORATION,, 6193,VisualEditor: Cursor jumps to the beginning of the sentence/paragraph when using jquery.IME,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",1425553166,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-hu7ibauxmtlo3ljy4pvq,task_subcomment,"I've set my Language settings on https://en.wikipedia.org to using native keyboard for Hindi input. > 5)Click on More, and using Media, select a couple of pictures > 6)Click on the tiny keyboard/typewriter and select language as Hindi or Telugu Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.","I've set my Language settings on URL to using native keyboard for Hindi input. QUOTE QUOTE Where exactly? In the ""alternative caption"" field of the ""Insert Image"" dialog? Some other field? The text of the page you edit? At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field. The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported). Clarification highly welcome.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,"[""I've set my Language settings on URL to using native keyboard for Hindi input."", 'QUOTE\nQUOTE\n\nWhere exactly?', 'In the ""alternative caption"" field of the ""Insert Image"" dialog?', 'Some other field?', 'The text of the page you edit?', 'At least for <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> and <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> I cannot reproduce any jumping back of the cursor in the ""alternative caption"" field.', 'The steps to reproduce this problem are a bit unclear (but probably only because the user interface has changed since this problem was reported).', 'Clarification highly welcome.']",NA,0,I've set my Language settings on URL to using native keyboard for Hindi input.,WORKAROUND,, 6275,VisualEditor: <pre> tags have leading whitespace removed,"Around the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",1379007960,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-six3hr3num5ryuty64kf,task_description,"VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: URL This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1379569694,NA,resolved,TRUE,c1,3,TRUE,FALSE,10,NA,"['VisualEditor: <pre> tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,VisualEditor: <pre> tags have leading whitespace removed.,OBSERVED BUG BEHAVIOR,, 6275,VisualEditor: <pre> tags have leading whitespace removed,"Around the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",1379007960,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-six3hr3num5ryuty64kf,task_description,"VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: URL This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1379569694,NA,resolved,TRUE,c1,3,TRUE,FALSE,10,NA,"['VisualEditor: <pre> tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.",OBSERVED BUG BEHAVIOR,, 6275,VisualEditor: <pre> tags have leading whitespace removed,"Around the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",1379007960,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-six3hr3num5ryuty64kf,task_description,"VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387 This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: <pre> tags have leading whitespace removed./n/nAround the time when VE started to support editing of pres we started to get dirty diffs like this: URL This might either be a selser issue, or VE dirtying the DOM. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1379569694,NA,resolved,TRUE,c1,3,TRUE,FALSE,10,NA,"['VisualEditor: <pre> tags have leading whitespace removed.', 'Around the time when VE started to support editing of pres we started to get dirty diffs like this:\n\nURL\n\nThis might either be a selser issue, or VE dirtying the DOM.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 6276,VisualEditor: <pre> tags have leading whitespace removed,*** Bug 53775 has been marked as a duplicate of this bug. ***,1379613849,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,*** Bug 53775 has been marked as a duplicate of this bug. ***,*** Bug 53775 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,"['*** Bug 53775 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 53775 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 6276,VisualEditor: <pre> tags have leading whitespace removed,*** Bug 53775 has been marked as a duplicate of this bug. ***,1379613849,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,*** Bug 53775 has been marked as a duplicate of this bug. ***,*** Bug 53775 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,"['*** Bug 53775 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 6277,VisualEditor: <pre> tags have leading whitespace removed,"Change 84896 merged by Catrope: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84896",1379545395,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"Change 84896 merged by Catrope: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84896","Change 84896 merged by Catrope: Fix check for preformatted when stripping whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,['Change 84896 merged by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL'],NA,0,Change 84896 merged by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL,TASK PROGRESS,, 6278,VisualEditor: <pre> tags have leading whitespace removed,"Change 84896 had a related patch set uploaded by Catrope: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84896",1379545270,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"Change 84896 had a related patch set uploaded by Catrope: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84896","Change 84896 had a related patch set uploaded by Catrope: Fix check for preformatted when stripping whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,['Change 84896 had a related patch set uploaded by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL'],NA,0,Change 84896 had a related patch set uploaded by Catrope:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL,TASK PROGRESS,, 6279,VisualEditor: <pre> tags have leading whitespace removed,"Change 84332 merged by jenkins-bot: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84332",1379466707,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"Change 84332 merged by jenkins-bot: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84332","Change 84332 merged by jenkins-bot: Fix check for preformatted when stripping whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,['Change 84332 merged by jenkins-bot:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL'],NA,0,Change 84332 merged by jenkins-bot:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL,TASK PROGRESS,, 6280,VisualEditor: <pre> tags have leading whitespace removed,"Change 84332 had a related patch set uploaded by Esanders: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84332",1379346257,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"Change 84332 had a related patch set uploaded by Esanders: Fix check for preformatted when stripping whitespace https://gerrit.wikimedia.org/r/84332","Change 84332 had a related patch set uploaded by Esanders: Fix check for preformatted when stripping whitespace GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,['Change 84332 had a related patch set uploaded by Esanders:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL'],NA,0,Change 84332 had a related patch set uploaded by Esanders:\nFix check for preformatted when stripping whitespace\n\nGERRIT_URL,TASK PROGRESS,, 6281,VisualEditor: <pre> tags have leading whitespace removed,"There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",1379008191,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,10,NA,"[""There's a check tag on the edit, so VE dirtied something somewhere."", 'That may or may not explain the whole bug, but we should fix it.']",NA,0,"That may or may not explain the whole bug, but we should fix it.",CONTRIBUTION AND COMMITMENT,, 6281,VisualEditor: <pre> tags have leading whitespace removed,"There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",1379008191,PHID-USER-fovtl67ew4l4cc3oeypc,PHID-TASK-six3hr3num5ryuty64kf,task_subcomment,"There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.","There's a check tag on the edit, so VE dirtied something somewhere. That may or may not explain the whole bug, but we should fix it.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,10,NA,"[""There's a check tag on the edit, so VE dirtied something somewhere."", 'That may or may not explain the whole bug, but we should fix it.']",NA,0,"There's a check tag on the edit, so VE dirtied something somewhere.",INVESTIGATION AND EXPLORATION,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,VisualEditor: Bypass browser blacklist.,OBSERVED BUG BEHAVIOR,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,Could we have a way to bypass the browser blacklist.,EXPECTED BEHAVIOR,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,e.g.,NA,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"1. a user preference to ignore the blacklist during initialisation, or\n2.",SOLUTION DISCUSSION,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.",SOLUTION USAGE,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.",SOLUTION DISCUSSION,, 7448,VisualEditor: Bypass browser blacklist,"Could we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900",1374370800,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_description,"VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=55900","VisualEditor: Bypass browser blacklist./n/nCould we have a way to bypass the browser blacklist. e.g. 1. a user preference to ignore the blacklist during initialisation, or 2. ?debug=true bypasses blacklist, 3. a test-wiki where the blacklist is empty/ignored, or 4. a simple way to re-run VE init from JS console This will allow mere mortals to help identify bugs with unsupported browsers. For option four, we can modify the blacklist, like so: JS> delete mw.libs.ve.blacklist.opera; But im not sure what to do after that. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1381630832,NA,resolved,TRUE,c1,3,FALSE,FALSE,2,NA,"['VisualEditor: Bypass browser blacklist.', 'Could we have a way to bypass the browser blacklist.', 'e.g.', '1. a user preference to ignore the blacklist during initialisation, or\n2.', '?debug=true bypasses blacklist,\n3. a test-wiki where the blacklist is empty/ignored, or\n4. a simple way to re-run VE init from JS console\n\nThis will allow mere mortals to help identify bugs with unsupported browsers.', 'For option four, we can modify the blacklist, like so:\n\nJS> delete mw.libs.ve.blacklist.opera;\n\nBut im not sure what to do after that.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 7449,VisualEditor: Bypass browser blacklist,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. https://gerrit.wikimedia.org/r/#/c/74574/ Changing from INVALID to FIXED, but maybe it is a dup of another bug?",1381630832,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_subcomment,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. https://gerrit.wikimedia.org/r/#/c/74574/ Changing from INVALID to FIXED, but maybe it is a dup of another bug?","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. URL Changing from INVALID to FIXED, but maybe it is a dup of another bug?",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,"[""The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time."", 'URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?']",NA,0,"URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?",ACTION ON ISSUE,, 7449,VisualEditor: Bypass browser blacklist,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. https://gerrit.wikimedia.org/r/#/c/74574/ Changing from INVALID to FIXED, but maybe it is a dup of another bug?",1381630832,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_subcomment,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. https://gerrit.wikimedia.org/r/#/c/74574/ Changing from INVALID to FIXED, but maybe it is a dup of another bug?","The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time. URL Changing from INVALID to FIXED, but maybe it is a dup of another bug?",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,"[""The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time."", 'URL\nChanging from INVALID to FIXED, but maybe it is a dup of another bug?']",NA,0,"The code for this enhancement request had already been written before the bug rasied, but wasn't deployed at that time.",TASK PROGRESS,, 7450,VisualEditor: Bypass browser blacklist,"You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!",1377532459,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-iycnxhmj2yiay4bvfsic,task_subcomment,"You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!","You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,8,NA,"['You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!']",NA,0,"You can already bypass the blacklist by using ?vewhitelist=1 - sorry, we should document this somewhere!",WORKAROUND,, 7451,VisualEditor: Bypass browser blacklist,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",1374372834,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_subcomment,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in URL Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,2,NA,"[""For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts."", 'Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.']",NA,0,"Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",SOLUTION DISCUSSION,, 7451,VisualEditor: Bypass browser blacklist,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",1374372834,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-iycnxhmj2yiay4bvfsic,task_subcomment,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in https://bits.wikimedia.org/static-1.22wmf10/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.","For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in URL Then execute JS> delete init.blacklist.opera And resume running the VE scripts. Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,2,NA,"[""For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts."", 'Im guessing this isnt possible on most mobile browsers, so one of option 1-3 or similar would be useful.']",NA,0,"For anyone wanting to bypass it on browser with a decent JS debugger, set a breakpoint on the line 'mw.libs.ve = init' in \n\nURL\n\nThen execute\nJS> delete init.blacklist.opera\n\nAnd resume running the VE scripts.",WORKAROUND,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,Support editing <references /> tags to set multi-column display on/off.,EXPECTED BEHAVIOR,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.,EXPECTED BEHAVIOR,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.",MOTIVATION,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.",INVESTIGATION AND EXPLORATION,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?,SOLUTION DISCUSSION,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.",SOLUTION DISCUSSION,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"**See Also**: T53145, T8019",INVESTIGATION AND EXPLORATION,, 7777,Support editing <references /> tags to set multi-column display on/off,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",1373662620,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_description,"Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[https://www.mediawiki.org/wiki/Extension:Cite|the Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-width|column widths]] rather than [[https://developer.mozilla.org/en-US/docs/Web/CSS/column-count|column counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019","Support editing <references /> tags to set multi-column display on/off./n/nFor VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag. Points of agreement include: * The main requirements are for <references /> to support multiple columns and different list styles ** T33597 discusses defaulting to multiple columns for all reference lists * Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size. This task is currently blocked, on the following issues: * What the default settings/algorithms should be * Whether column widths and list styles should be customizable per-page, or only per-wiki * If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level. This would involve adding: * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not allowing width, obviously) * list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL) Then we could just bot-substitute uses of the template, and everyone would be happy. **See Also**: T53145, T8019",Medium,50,1505846752,PHID-USER-kve2ug5yc3dp6ighnmqk,resolved,TRUE,c1,3,TRUE,FALSE,1,NA,"['Support editing <references /> tags to set multi-column display on/off.', ""For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769)."", 'It would be much easier for everyone if we just moved the features provided by such templates into [[URL Cite extension]] itself and allowed such templates to be replaced by the now more powerful <references /> tag.', 'Points of agreement include:\n* The main requirements are for <references /> to support multiple columns and different list styles\n** T33597 discusses defaulting to multiple columns for all reference lists\n* Columns should be implemented using [[URL widths]] rather than [[URL counts]], to allow flexibility based on screen size.', 'This task is currently blocked, on the following issues:\n* What the default settings/algorithms should be\n* Whether column widths and list styles should be customizable per-page, or only per-wiki \n* If per-page customizations are allowed, whether they should be implemented by passing through CSS properties from the invocation of the <references /> tag or by applying CSS classes, which are then given CSS properties on a per-wiki or global level.', 'This would involve adding:\n\n* columns (default to 1; a number between 1 and <20><><EFBFBD> another number?', '- not allowing width, obviously)\n* list-style (default to decimal; just an escaped pass-through of the CSS list-style of the OL)\n\nThen we could just bot-substitute uses of the template, and everyone would be happy.', '**See Also**: T53145, T8019']",FALSE,0,"For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769).",OBSERVED BUG BEHAVIOR,, 7778,Support editing <references /> tags to set multi-column display on/off,"Change 378935 merged by jenkins-bot: [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[https://gerrit.wikimedia.org/r/378935]] ",1505840824,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 378935 merged by jenkins-bot: [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[https://gerrit.wikimedia.org/r/378935]] ","Change 378935 merged by jenkins-bot: [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,220,NA,"[""Change 378935 merged by jenkins-bot:\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]""]",NA,0,Change 378935 merged by jenkins-bot:\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]],TASK PROGRESS,, 7779,Support editing <references /> tags to set multi-column display on/off,"Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders): [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[https://gerrit.wikimedia.org/r/378935]] ",1505835365,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders): [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[https://gerrit.wikimedia.org/r/378935]] ","Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders): [mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,220,NA,"[""Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]]""]",NA,0,Change 378935 had a related patch set uploaded (by Esanders; owner: Esanders):\n[mediawiki/extensions/Cite@master] VE: Support 'responsive' attribute\n\n[[GERRIT_URL]],TASK PROGRESS,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).",FUTURE PLANS,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"* there is also a rather large documentation gap, atm.",POTENTIAL NEW ISSUES AND REQUESTS,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,regarding new and old information.,SOLUTION DISCUSSION,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").",INVESTIGATION AND EXPLORATION,X, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,Just a thought.,SOCIAL CONVERSATION,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns.",CONTRIBUTION AND COMMITMENT,, 7780,Support editing <references /> tags to set multi-column display on/off,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",1499785680,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.","FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns. Next step for en.wp will be to enables responsive by default for a plain <references> element This leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element # Different list item counters # Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour). This doesn't negate the fact that: * of course reflist is already universally used, and universally changing it will probably be seen as disruptive. * there is also a rather large documentation gap, atm. regarding new and old information. * ironically, it seems that the responsive attribute cannot be set/unset from VE An idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element""). Just a thought.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,210,NA,"[""FYI, I've added some support to en.wp's {{reflist}} to explicitly enable and disable automatic columns."", 'Next step for en.wp will be to enables responsive by default for a plain <references> element\n\nThis leaves the following capabilities that are specific to Reflist, which currently cannot be fulfilled with a plain references element\n# Different list item counters\n# Differing column widths (this one is also not really compatible with automatic columns, which will create a bit of a disjunct in behaviour).', ""This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive."", '* there is also a rather large documentation gap, atm.', 'regarding new and old information.', '* ironically, it seems that the responsive attribute cannot be set/unset from VE\n\nAn idea that played in my mind, which would be terribly WMF specific, but might make it easier to work with this problem, is if we should maybe change the VE editor of <references/> and the Template:Reflist, to be aware of each other, and maybe offer the opportunity to switch between them (""more options"", vs ""convert to references element"").', 'Just a thought.']",NA,0,"This doesn't negate the fact that:\n* of course reflist is already universally used, and universally changing it will probably be seen as disruptive.",SOLUTION USAGE,, 7781,Support editing <references /> tags to set multi-column display on/off,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,PHID-USER-o7sy7j32bv4qerbqa3x5,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE QUOTE You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle.",SOCIAL CONVERSATION,, 7781,Support editing <references /> tags to set multi-column display on/off,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,PHID-USER-o7sy7j32bv4qerbqa3x5,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE QUOTE You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769.",ISSUE CONTENT MANAGEMENT,, 7781,Support editing <references /> tags to set multi-column display on/off,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,PHID-USER-o7sy7j32bv4qerbqa3x5,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE QUOTE You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates.,SOLUTION DISCUSSION ,, 7781,Support editing <references /> tags to set multi-column display on/off,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,PHID-USER-o7sy7j32bv4qerbqa3x5,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE QUOTE You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,"If that's the purpose of this bug, it's a failure when it still gets templated.",SOLUTION USAGE,, 7781,Support editing <references /> tags to set multi-column display on/off,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",1446974679,PHID-USER-o7sy7j32bv4qerbqa3x5,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,">For VisualEditor, we are continuously-bitten by <references /> tags that are embedded within generated content like the English Wikipedia's {{reflist}} (T52769). It would be much easier for everyone if we just moved the features provided by such templates into the Cite extension itself and allowed such templates to be replaced by the now more powerful <references /> tag. >Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-) You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.","QUOTE QUOTE You're contradicting yourself, chuckle. I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769. This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates. If that's the purpose of this bug, it's a failure when it still gets templated. This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,122,NA,"[""QUOTE\n\nQUOTE\n\nYou're contradicting yourself, chuckle."", ""I agree with the second statement, fixing VisualEditor's difficulties with templates is bug T52769."", ""This proposal of a more powerful more powerful <references /> tag isn't going to help that bug because communities will still have various reasons for putting things inside various templates."", ""If that's the purpose of this bug, it's a failure when it still gets templated."", ""This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.""]",NA,0,This bug really only makes sense in light of something like //T33597: Render references list in multiple columns based on the number of items// which aims to add useful new functionality regardless of whether it's put inside a template.,INVESTIGATION AND EXPLORATION,, 7782,Support editing <references /> tags to set multi-column display on/off,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,1435699557,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,104,NA,"['This was discussed at the weekly meeting on 2015-06-30.', ""We decided that it wasn't a priority for this quarter.""]",NA,0,This was discussed at the weekly meeting on 2015-06-30.,ISSUE CONTENT MANAGEMENT,X, 7782,Support editing <references /> tags to set multi-column display on/off,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,1435699557,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,This was discussed at the weekly meeting on 2015-06-30. We decided that it wasn't a priority for this quarter.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,104,NA,"['This was discussed at the weekly meeting on 2015-06-30.', ""We decided that it wasn't a priority for this quarter.""]",NA,0,We decided that it wasn't a priority for this quarter.,ISSUE CONTENT MANAGEMENT,X, 7783,Support editing <references /> tags to set multi-column display on/off,It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).,1425310977,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).,It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,87,NA,['It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).'],NA,0,It should be noted that mobilefrontend already does some CSS overrides here (setting a default column width).,SOLUTION DISCUSSION,, 7784,Support editing <references /> tags to set multi-column display on/off,@thiemowmde mentions T33597,1416834442,PHID-USER-tqvzwasywo4a7bnuwuz4,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,@thiemowmde mentions T33597,SCREEN_NAME mentions T33597,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,73,NA,['SCREEN_NAME mentions T33597'],NA,0,SCREEN_NAME mentions T33597,INVESTIGATION AND EXPLORATION,, 7785,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,1416910461,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 (T33597) for a much more elaborate proposal.']",NA,0,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.,SOCIAL CONVERSATION,, 7785,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,1416910461,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 (T33597) for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 (T33597) for a much more elaborate proposal.']",NA,0,See bug 31597 (T33597) for a much more elaborate proposal.,ISSUE CONTENT MANAGEMENT,, 7786,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,1416910421,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See T31597 for a much more elaborate proposal.']",NA,0,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.,SOCIAL CONVERSATION,, 7786,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,1416910421,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See T31597 for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,73,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See T31597 for a much more elaborate proposal.']",NA,0,See T31597 for a much more elaborate proposal.,ISSUE CONTENT MANAGEMENT,, 7787,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,1412760097,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,66,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 for a much more elaborate proposal.']",NA,0,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.,SOCIAL CONVERSATION,, 7787,Support editing <references /> tags to set multi-column display on/off,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,1412760097,PHID-USER-u6ycqhfpa3k4yvlpxjt2,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said. See bug 31597 for a much more elaborate proposal.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,66,NA,"['Just to make this clear (since I was told to say this here rather than in Gerrit): 100% agree to what Krinkle and Gabriel said.', 'See bug 31597 for a much more elaborate proposal.']",NA,0,See bug 31597 for a much more elaborate proposal.,ISSUE CONTENT MANAGEMENT,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,These are traditionally implemented in a CODE template on Wikipedia.,SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,That was by all accounts a compromise due to the limited capability they have inside a template.,INVESTIGATION AND EXPLORATION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,What people want is for stuff to just work.,MOTIVATION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.,FUTURE PLANS,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.",MOTIVATION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"The number of columns should be determined by width, not hardcoded count.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,Not a burden for the users.,SOLUTION USAGE,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,And it can be improved as we collect more data and positively influence all readers.,FUTURE PLANS,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"They vary by device, browser, etc.",BUG REPRODUCTION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,It will traditionally and up with authors using their personal preference for what looks right on their device.,SOLUTION USAGE,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.",POTENTIAL NEW ISSUES AND REQUESTS,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.,MOTIVATION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,They don't actually want to specify it manually each time.,MOTIVATION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).",SOLUTION USAGE,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article.",SOLUTION DISCUSSION,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language.",SOLUTION DISCUSSION ,, 7788,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",1417405037,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.""]",NA,0,"Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need either.",MOTIVATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,These are traditionally implemented in a CODE template on Wikipedia.,SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,That was by all accounts a compromise due to the limited capability they have inside a template.,INVESTIGATION AND EXPLORATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,What people want is for stuff to just work.,MOTIVATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.,FUTURE PLANS,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.",MOTIVATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The number of columns should be determined by width, not hardcoded count.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,Not a burden for the users.,SOLUTION USAGE,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,And it can be improved as we collect more data and positively influence all readers.,FUTURE PLANS,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They vary by device, browser, etc.",BUG REPRODUCTION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,It will traditionally and up with authors using their personal preference for what looks right on their device.,SOLUTION USAGE,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.",POTENTIAL NEW ISSUES AND REQUESTS,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list.,MOTIVATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,They don't actually want to specify it manually each time.,MOTIVATION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).",SOLUTION USAGE,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article.",SOLUTION DISCUSSION,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language.",SOLUTION DISCUSSION ,, 7789,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1417405028,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual `<references>` list. These are traditionally implemented in a `{{reflist}}` template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list. These are traditionally implemented in a CODE template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,74,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual CODE list."", 'These are traditionally implemented in a CODE template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Note: Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",MOTIVATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,These are traditionally implemented in a {{reflist}} template on Wikipedia.,SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,That was by all accounts a compromise due to the limited capability they have inside a template.,INVESTIGATION AND EXPLORATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,What people want is for stuff to just work.,MOTIVATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.,FUTURE PLANS,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.",MOTIVATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The number of columns should be determined by width, not hardcoded count.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"And while the latest patch uses width, it is still imho fundamentally flawed.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,Not a burden for the users.,SOLUTION USAGE,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Based on design considerations, can make a reasonable choice for what the column width should be.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,And it can be improved as we collect more data and positively influence all readers.,FUTURE PLANS,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"They vary by device, browser, etc.",BUG REPRODUCTION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,It will traditionally and up with authors using their personal preference for what looks right on their device.,SOLUTION USAGE,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.",POTENTIAL NEW ISSUES AND REQUESTS,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list.,MOTIVATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,They don't actually want to specify it manually each time.,MOTIVATION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki).",SOLUTION USAGE,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If this were any other feature, it'd be obvious this is something for the software to provide as a convenience.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article.",SOLUTION DISCUSSION,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language.",SOLUTION DISCUSSION ,, 7790,Support editing <references /> tags to set multi-column display on/off,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",1412722649,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.","I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list. These are traditionally implemented in a {{reflist}} template on Wikipedia. That was by all accounts a compromise due to the limited capability they have inside a template. What people want is for stuff to just work. They don't actually want to specify it manually each time. Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards. There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style. The number of columns should be determined by width, not hardcoded count. And while the latest patch uses width, it is still imho fundamentally flawed. Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki). If this were any other feature, it'd be obvious this is something for the software to provide as a convenience. Not a burden for the users. Based on design considerations, can make a reasonable choice for what the column width should be. And it can be improved as we collect more data and positively influence all readers. While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article. They vary by device, browser, etc. It will traditionally and up with authors using their personal preference for what looks right on their device. The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about. If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language. One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed. -- Gabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,66,NA,"[""I fail to see how it is in anyone's best interest to implement support for list-style and column sizes on an individual <references> list."", 'These are traditionally implemented in a {{reflist}} template on Wikipedia.', 'That was by all accounts a compromise due to the limited capability they have inside a template.', 'What people want is for stuff to just work.', ""They don't actually want to specify it manually each time."", 'Adding this to the extension will improve nothing other than move it from a template hack to something we now have to support and maintain forwards.', 'There has yet to be given a valid reason for why anyone would explicitly, semantically, by intent, want one specific article to have its references in a certain number of columns or certain list item number style.', 'The number of columns should be determined by width, not hardcoded count.', 'And while the latest patch uses width, it is still imho fundamentally flawed.', ""Users don't want to hardcode this everywhere (authors will not know this even exists, leading to generally no single user actually using this feature other than power users, whom then have to write bots that fix it everywhere; or more likely, they'll just use another template that specified the width and list-style they agree on for that wiki)."", ""If this were any other feature, it'd be obvious this is something for the software to provide as a convenience."", 'Not a burden for the users.', 'Based on design considerations, can make a reasonable choice for what the column width should be.', 'And it can be improved as we collect more data and positively influence all readers.', ""While there may not be a perfect value, I know for sure the factors that make it less perfect don't vary by article."", 'They vary by device, browser, etc.', 'It will traditionally and up with authors using their personal preference for what looks right on their device.', 'The only thing that is probably in need of variation is list-style (based on content language), which, again, seems like something we can be much smarter about.', ""If there isn't a way to get that already from the Language infrastructure, we can provide a config variable or mediawiki-message specifying the list-style for that wiki or language."", 'One exception could be multi-lingual wikis, so maybe provide list-style as attribute indeed.', ""--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.""]",NA,0,"--\n\nGabriels proposal for css classes is imho better than providing a hardcoded column-width, but per the above, we don't need neither.",MOTIVATION,, 7791,Support editing <references /> tags to set multi-column display on/off,"See also: Bug 31597 - generate class for references list according to the number of refs",1411551743,PHID-USER-zqde3skdzpqiwny4dxt4,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"See also: Bug 31597 - generate class for references list according to the number of refs","See also: Bug 31597 - generate class for references list according to the number of refs",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,64,NA,['See also:\nBug 31597 - generate class for references list according to the number of refs'],NA,0,See also:\nBug 31597 - generate class for references list according to the number of refs,INVESTIGATION AND EXPLORATION,, 7792,Support editing <references /> tags to set multi-column display on/off,"Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: ok done https://gerrit.wikimedia.org/r/123105",1409791989,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: ok done https://gerrit.wikimedia.org/r/123105","Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: ok done GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"[""Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nReason:\nok done\n\nGERRIT_URL""]",NA,0,Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nReason:\nok done\n\nGERRIT_URL,TASK PROGRESS,, 7793,Support editing <references /> tags to set multi-column display on/off,I picked up the Cite & VE parts of this again.,1409791787,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,I picked up the Cite & VE parts of this again.,I picked up the Cite & VE parts of this again.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,61,NA,['I picked up the Cite & VE parts of this again.'],NA,0,I picked up the Cite & VE parts of this again.,CONTRIBUTION AND COMMITMENT,, 7794,Support editing <references /> tags to set multi-column display on/off,"Change 123105 restored by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: Restoring so I can do a rebase to get the VE patch working https://gerrit.wikimedia.org/r/123105",1409791573,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123105 restored by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: Restoring so I can do a rebase to get the VE patch working https://gerrit.wikimedia.org/r/123105","Change 123105 restored by Alex Monk: Support new column-width and list-style attributes to Cite's <references> Reason: Restoring so I can do a rebase to get the VE patch working GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"[""Change 123105 restored by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nReason:\nRestoring so I can do a rebase to get the VE patch working\n\nGERRIT_URL""]",NA,0,Change 123105 restored by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nReason:\nRestoring so I can do a rebase to get the VE patch working\n\nGERRIT_URL,TASK PROGRESS,, 7795,Support editing <references /> tags to set multi-column display on/off,"Change 123093 restored by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123093",1409782437,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123093 restored by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123093","Change 123093 restored by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"[""Change 123093 restored by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's <references>\n\nGERRIT_URL""]",NA,0,Change 123093 restored by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's <references>\n\nGERRIT_URL,TASK PROGRESS,, 7796,Support editing <references /> tags to set multi-column display on/off,"Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. https://gerrit.wikimedia.org/r/120962",1409782408,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. https://gerrit.wikimedia.org/r/120962","Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"['Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nReason:\nGoing to use classes.', 'GERRIT_URL']",NA,0,Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nReason:\nGoing to use classes.,TASK PROGRESS,, 7796,Support editing <references /> tags to set multi-column display on/off,"Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. https://gerrit.wikimedia.org/r/120962",1409782408,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. https://gerrit.wikimedia.org/r/120962","Change 120962 restored by Alex Monk: Support setting column-width and list-style in <references /> tag Reason: Going to use classes. GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,61,NA,"['Change 120962 restored by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nReason:\nGoing to use classes.', 'GERRIT_URL']",NA,0,GERRIT_URL,TASK PROGRESS,, 7797,Support editing <references /> tags to set multi-column display on/off,Bug 22265 - Allow references to be listed with letters,1405984158,PHID-USER-zqde3skdzpqiwny4dxt4,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Bug 22265 - Allow references to be listed with letters,Bug 22265 - Allow references to be listed with letters,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,55,NA,['Bug 22265 - Allow references to be listed with letters'],NA,0,Bug 22265 - Allow references to be listed with letters,INVESTIGATION AND EXPLORATION,, 7798,Support editing <references /> tags to set multi-column display on/off,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,No.,SOCIAL CONVERSATION,, 7798,Support editing <references /> tags to set multi-column display on/off,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,We /are/ going to do this.,CONTRIBUTION AND COMMITMENT,, 7798,Support editing <references /> tags to set multi-column display on/off,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,"Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.",CONTRIBUTION AND COMMITMENT,, 7798,Support editing <references /> tags to set multi-column display on/off,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,It certainly isn\,SOCIAL CONVERSATION,, 7798,Support editing <references /> tags to set multi-column display on/off,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",1405787640,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".","No. We /are/ going to do this. Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way. It certainly isn't ""UNCONFIRMED"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,54,NA,"['No.', 'We /are/ going to do this.', 'Gabriel is on the hook for suggesting how to do it in a way that makes him happy, given he vetoed the agreed way.', 'It certainly isn\'t ""UNCONFIRMED"".']",NA,0,UNCONFIRMED,NA,, 7799,Support editing <references /> tags to set multi-column display on/off,"Change 123093 abandoned by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> Reason: Abandoning all related patch sets https://gerrit.wikimedia.org/r/123093",1405780950,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123093 abandoned by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> Reason: Abandoning all related patch sets https://gerrit.wikimedia.org/r/123093","Change 123093 abandoned by Alex Monk: WIP Support new column-width & list-style attributes to Cite's <references> Reason: Abandoning all related patch sets GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,54,NA,"[""Change 123093 abandoned by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's <references>\n\nReason:\nAbandoning all related patch sets\n\nGERRIT_URL""]",NA,0,Change 123093 abandoned by Alex Monk:\nWIP Support new column-width & list-style attributes to Cite's <references>\n\nReason:\nAbandoning all related patch sets\n\nGERRIT_URL,TASK PROGRESS,, 7800,Support editing <references /> tags to set multi-column display on/off,"Change 120962 abandoned by Alex Monk: Support setting column-width and list-style in <references /> tag https://gerrit.wikimedia.org/r/120962",1405780903,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 120962 abandoned by Alex Monk: Support setting column-width and list-style in <references /> tag https://gerrit.wikimedia.org/r/120962","Change 120962 abandoned by Alex Monk: Support setting column-width and list-style in <references /> tag GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,54,NA,['Change 120962 abandoned by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nGERRIT_URL'],NA,0,Change 120962 abandoned by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nGERRIT_URL,TASK PROGRESS,, 7801,Support editing <references /> tags to set multi-column display on/off,"Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123105",1405780885,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123105","Change 123105 abandoned by Alex Monk: Support new column-width and list-style attributes to Cite's <references> GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,54,NA,"[""Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL""]",NA,0,Change 123105 abandoned by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL,TASK PROGRESS,, 7802,Support editing <references /> tags to set multi-column display on/off,See https://gerrit.wikimedia.org/r/#/c/120962/ for more discussion on this.,1401486377,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,See https://gerrit.wikimedia.org/r/#/c/120962/ for more discussion on this.,See URL for more discussion on this.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,47,NA,['See URL for more discussion on this.'],NA,0,See URL for more discussion on this.,ISSUE CONTENT MANAGEMENT,, 7803,Support editing <references /> tags to set multi-column display on/off,"(In reply to Gabriel Wicke from comment #24) > Is there a good reason to use magic attributes and inline styles here > instead of CSS classes? The latter is easier to customize for different > environments and creates less complexity in the parsers (PHP and Parsoid). > > All VE needs is a list of classes to offer in a drop-down or the like. Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality<74><79><EFBFBD>",1401482644,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Gabriel Wicke from comment #24) > Is there a good reason to use magic attributes and inline styles here > instead of CSS classes? The latter is easier to customize for different > environments and creates less complexity in the parsers (PHP and Parsoid). > > All VE needs is a list of classes to offer in a drop-down or the like. Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality<74><79><EFBFBD>","(In reply to Gabriel Wicke from comment #24) QUOTE QUOTE QUOTE QUOTE QUOTE Your assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality<74><79><EFBFBD>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,47,NA,"[""(In reply to Gabriel Wicke from comment #24)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYour assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality<74><79><EFBFBD>""]",NA,0,(In reply to Gabriel Wicke from comment #24)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYour assertion that a restricted set of classes invented by the development team will be sufficient for the community's existing wishes to be fulfilled is not met by reality<74><79><EFBFBD>,SOLUTION DISCUSSION,X, 7804,Support editing <references /> tags to set multi-column display on/off,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,Is there a good reason to use magic attributes and inline styles here instead of CSS classes?,SOLUTION DISCUSSION,, 7804,Support editing <references /> tags to set multi-column display on/off,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).,SOLUTION DISCUSSION,, 7804,Support editing <references /> tags to set multi-column display on/off,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",1396389434,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.","Is there a good reason to use magic attributes and inline styles here instead of CSS classes? The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid). All VE needs is a list of classes to offer in a drop-down or the like.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,39,NA,"['Is there a good reason to use magic attributes and inline styles here instead of CSS classes?', 'The latter is easier to customize for different environments and creates less complexity in the parsers (PHP and Parsoid).', 'All VE needs is a list of classes to offer in a drop-down or the like.']",NA,0,All VE needs is a list of classes to offer in a drop-down or the like.,SOLUTION DISCUSSION,, 7805,Support editing <references /> tags to set multi-column display on/off,"Change 123105 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123105",1396388659,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123105 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123105","Change 123105 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,39,NA,"[""Change 123105 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL""]",NA,0,Change 123105 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL,TASK PROGRESS,, 7806,Support editing <references /> tags to set multi-column display on/off,"Change 123093 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123093",1396387228,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 123093 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> https://gerrit.wikimedia.org/r/123093","Change 123093 had a related patch set uploaded by Alex Monk: Support new column-width and list-style attributes to Cite's <references> GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,39,NA,"[""Change 123093 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL""]",NA,0,Change 123093 had a related patch set uploaded by Alex Monk:\nSupport new column-width and list-style attributes to Cite's <references>\n\nGERRIT_URL,TASK PROGRESS,, 7807,Support editing <references /> tags to set multi-column display on/off,"What? We don't do LATER, and haven't for over a year.",1395858396,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"What? We don't do LATER, and haven't for over a year.","What? We don't do LATER, and haven't for over a year.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,38,NA,"['What?', ""We don't do LATER, and haven't for over a year.""]",NA,0,What?,SOCIAL CONVERSATION,, 7807,Support editing <references /> tags to set multi-column display on/off,"What? We don't do LATER, and haven't for over a year.",1395858396,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"What? We don't do LATER, and haven't for over a year.","What? We don't do LATER, and haven't for over a year.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,38,NA,"['What?', ""We don't do LATER, and haven't for over a year.""]",NA,0,"We don't do LATER, and haven't for over a year.",ACTION ON ISSUE,, 7808,Support editing <references /> tags to set multi-column display on/off,"IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.",1395800703,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.","IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,38,NA,"['IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.']",NA,0,"IMO this should be a WONTFIX or LATER, and instead bug 6019 should be fixed.",ACTION ON ISSUE,, 7809,Support editing <references /> tags to set multi-column display on/off,"Change 120962 had a related patch set uploaded by Alex Monk: Support setting column-width and list-style in <references /> tag https://gerrit.wikimedia.org/r/120962",1395789394,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Change 120962 had a related patch set uploaded by Alex Monk: Support setting column-width and list-style in <references /> tag https://gerrit.wikimedia.org/r/120962","Change 120962 had a related patch set uploaded by Alex Monk: Support setting column-width and list-style in <references /> tag GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,38,NA,['Change 120962 had a related patch set uploaded by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nGERRIT_URL'],NA,0,Change 120962 had a related patch set uploaded by Alex Monk:\nSupport setting column-width and list-style in <references /> tag\n\nGERRIT_URL,TASK PROGRESS,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.",SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).,SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,** Make it look nice.,SOCIAL CONVERSATION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,:-)\n\n** Should this default be variable as a per-wiki option?,SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.",SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,** Should this default be variable as a per-wiki/per-content-language option?,SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.",SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\",POTENTIAL NEW ISSUES AND REQUESTS,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,t be encouraged).,SOCIAL CONVERSATION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,"* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.",SOLUTION DISCUSSION,, 7810,Support editing <references /> tags to set multi-column display on/off,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",1394727173,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to Alex Monk from comment #17) > Can someone sum up exactly what has been agreed to do here? My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?","(In reply to Alex Monk from comment #17) QUOTE My understanding: Do: * Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width. ** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL). ** Make it look nice. :-) ** Should this default be variable as a per-wiki option? * Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal. ** Should this default be variable as a per-wiki/per-content-language option? I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal. Do not: * Add a ""columns"" property (this breaks the concept of the Web's content being fit for any sized screen and shouldn't be encouraged). * Add a new class to the <references /> OL <20><><EFBFBD><EFBFBD><EFBFBD>the ""references"" class can be over-ridden locally by wikis if they want to change it further. Is this what others think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['(In reply to Alex Monk from comment #17)\nQUOTE\n\nMy understanding:\n\nDo: \n\n* Add a ""column-width"" optional property to the <references /> element, in ems, defaulting to unspecified => one column of 100% width.', '** Ensure the issues about RTL display being logical are fix (you need to make sure that the columns and their contents both flow RTL).', '** Make it look nice.', ':-)\n\n** Should this default be variable as a per-wiki option?', '* Add a ""list-style"" optional property to the <references /> element, an escaped pass-through of the CSS list-style of the OL, defaulting to decimal.', '** Should this default be variable as a per-wiki/per-content-language option?', 'I can imagine there might be better alternatives for some languages than ""Arabic"" Roman decimal.', 'Do not:\n\n* Add a ""columns"" property (this breaks the concept of the Web\'s content being fit for any sized screen and shouldn\'t be encouraged).', '* Add a new class to the <references /> OL <20><><EFBFBD>\xa0the ""references"" class can be over-ridden locally by wikis if they want to change it further.', 'Is this what others think?']",NA,0,Is this what others think?,SOCIAL CONVERSATION,, 7811,Support editing <references /> tags to set multi-column display on/off,Can someone sum up exactly what has been agreed to do here?,1394128243,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,Can someone sum up exactly what has been agreed to do here?,Can someone sum up exactly what has been agreed to do here?,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,35,NA,['Can someone sum up exactly what has been agreed to do here?'],NA,0,Can someone sum up exactly what has been agreed to do here?,ISSUE CONTENT MANAGEMENT,, 7812,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8) QUOTE QUOTE This is bug 6019. QUOTE Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.,INVESTIGATION AND EXPLORATION,, 7812,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8) QUOTE QUOTE This is bug 6019. QUOTE Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?,INVESTIGATION AND EXPLORATION,, 7812,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8) QUOTE QUOTE This is bug 6019. QUOTE Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,I am wondering whether Cite adding a class for the group name will suffice.,WORKAROUND,, 7812,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8) QUOTE QUOTE This is bug 6019. QUOTE Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,(i.e.,NA,, 7812,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",1383136097,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #8) > The references tag should support html attributes, than you can write > <references class=""***"" /> and the template can be replaced. This is bug 6019. > Needs a set up a class for list-styles. Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.","(In reply to comment #8) QUOTE QUOTE This is bug 6019. QUOTE Has anyone done an analysis of list-style usage on the large wikis? I am wondering whether Cite adding a class for the group name will suffice. (i.e. emitting class=""references references-$group $invocationClassesVal"") I agree with others that Cite shouldn't add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['(In reply to comment #8)\nQUOTE\nQUOTE\n\nThis is bug 6019.', 'QUOTE\n\nHas anyone done an analysis of list-style usage on the large wikis?', 'I am wondering whether Cite adding a class for the group name will suffice.', '(i.e.', 'emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\'t add explicit support for columns, as this is very device-dependent; a class attribute indirectly provides this and more.']",NA,0,"emitting class=""references references-$group $invocationClassesVal"") \n\nI agree with others that Cite shouldn\",EXPECTED BEHAVIOR,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,Multiple columns for references causes two major usability issues:\n\n1.,SOLUTION DISCUSSION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.",OBSERVED BUG BEHAVIOR,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.",BUG REPRODUCTION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,2,NA,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.",OBSERVED BUG BEHAVIOR,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.",BUG REPRODUCTION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,b) You have to scroll down to the beginning of the reference and start reading.,BUG REPRODUCTION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,c) You have to scroll up again to the second part and continue reading.,BUG REPRODUCTION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,d) If you don\,NA,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"s ""back"" function, you have to scroll down again to get to the back link.",BUG REPRODUCTION,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.",POTENTIAL NEW ISSUES AND REQUESTS,, 7813,Support editing <references /> tags to set multi-column display on/off,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",1383132465,PHID-USER-tyjmn7xcw6s2b6rqagj7,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.","Multiple columns for references causes two major usability issues: 1. When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference. This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc. 2. When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it. This means: a) You click the superscript number, the browser sends you to the upper part of the reference. b) You have to scroll down to the beginning of the reference and start reading. c) You have to scroll up again to the second part and continue reading. d) If you don't know that you can use your browser's ""back"" function, you have to scroll down again to get to the back link. Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor. So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,17,NA,"['Multiple columns for references causes two major usability issues:\n\n1.', 'When there is only one reference and this reference is longer than the column width, it is split into several parts, causing gaps inside the reference.', 'This gets even worse for bidi texts: If you have a reference in a right-to-left language inside a left-to-right context, and it is split into multiple columns, you have to start reading on the right end of the left column, read to the left, jump right to the next column, read to the left again, etc.', '2.', 'When the list of references is longer than the screen and a reference breaks into two columns, you have to scroll to read it.', 'This means:\na) You click the superscript number, the browser sends you to the upper part of the reference.', 'b) You have to scroll down to the beginning of the reference and start reading.', 'c) You have to scroll up again to the second part and continue reading.', 'd) If you don\'t know that you can use your browser\'s ""back"" function, you have to scroll down again to get to the back link.', 'Both issues could be solved by using ""break-inside: avoid-column;"", but the browser support currently is very poor.', 'So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.']",NA,0,"So unless browser support for this improves in future or somebody writes a JS solution for it, multi-column reference lists are a bad idea for usability reasons.",FUTURE PLANS,, 7814,Support editing <references /> tags to set multi-column display on/off,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,"For the record, both column-count and column-width are fully automated CSS properties in the browser.",INVESTIGATION AND EXPLORATION,, 7814,Support editing <references /> tags to set multi-column display on/off,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,No development on our side to split the list or anything like that.,SOLUTION DISCUSSION ,, 7814,Support editing <references /> tags to set multi-column display on/off,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",1380273005,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.","For the record, both column-count and column-width are fully automated CSS properties in the browser. It's 1 line of code to tell the browser, and then browsers handle it natively for us. No development on our side to split the list or anything like that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['For the record, both column-count and column-width are fully automated CSS properties in the browser.', ""It's 1 line of code to tell the browser, and then browsers handle it natively for us."", 'No development on our side to split the list or anything like that.']",NA,0,"It's 1 line of code to tell the browser, and then browsers handle it natively for us.",SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.",OBSERVED BUG BEHAVIOR,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"When viewing it on a narrower window, it becomes unreadable.",OBSERVED BUG BEHAVIOR,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.",SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,The result is a chaos if different column counts per article.,SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.",FUTURE PLANS,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).",SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,Probably deriving it from the number of references in the list.,SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.",SOLUTION DISCUSSION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,</brain-dump>,SOCIAL CONVERSATION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason.",INVESTIGATION AND EXPLORATION,, 7815,Support editing <references /> tags to set multi-column display on/off,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",1380272763,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>","column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins. When viewing it on a narrower window, it becomes unreadable. column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist. What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason. The result is a chaos if different column counts per article. When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from. Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3). Probably deriving it from the number of references in the list. column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider. Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case). </brain-dump>",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['column-count is terrible indeed, especially for liquid layouts like in MediaWiki skins.', 'When viewing it on a narrower window, it becomes unreadable.', 'column-width is a much more sensible approach, though I find it hard to believe either makes sense to be specified on the individual reflist.', ""What I've seen in practice (at least on nl.wikipedia) that there is authors who know about it and explicitly use reflist with 2 columns in all their articles, and others who don't know about it, and others who prefer 3 for whatever reason."", 'The result is a chaos if different column counts per article.', 'When incorporating this back into the Cite extension, we can also provide a better default based on whatever really makes sense to derive it from.', 'Whatever the rational is for needing multiple columns (mostly for readability I presume as the lines become too wide, and the list too long), we can automate that trivially based on rational UX arguments (yes, there shall be a global wiki bikeshed about why 2 is better than 3).', 'Probably deriving it from the number of references in the list.', 'column-width will allow the list to fold back into 1 column on smaller devices and people who just like to narrow their window, and multiply out as the window gets wider.', ""Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case)."", '</brain-dump>']",NA,0,"Of course this problem isn't entirely specific to references lists, it's also a long outstanding petpeeve of various designers about the article content itself, a fluid layout makes that content hard to read as well in some cases (though a fixed layout is probably better than multi-column in that case).",INVESTIGATION AND EXPLORATION,, 7816,Support editing <references /> tags to set multi-column display on/off,What about the {{reflist}} variants on en.wiki such as {{notelist}}?,1377709374,PHID-USER-zqde3skdzpqiwny4dxt4,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,What about the {{reflist}} variants on en.wiki such as {{notelist}}?,What about the {{reflist}} variants on en.wiki such as {{notelist}}?,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,8,NA,['What about the {{reflist}} variants on en.wiki such as {{notelist}}?'],NA,0,What about the {{reflist}} variants on en.wiki such as {{notelist}}?,INVESTIGATION AND EXPLORATION,, 7817,Support editing <references /> tags to set multi-column display on/off,"The plwp infobox <references/> is here: https://pl.wikipedia.org/wiki/Szablon:Infobox_uwagi_dodaj",1373764541,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The plwp infobox <references/> is here: https://pl.wikipedia.org/wiki/Szablon:Infobox_uwagi_dodaj","The plwp infobox <references/> is here: URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,['The plwp infobox <references/> is here:\nURL'],NA,0,The plwp infobox <references/> is here:\nURL,INVESTIGATION AND EXPLORATION,, 7818,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?)"", 'have to embed <references /> in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,have to embed <references /> in templates.,SOLUTION DISCUSSION,, 7818,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?)"", 'have to embed <references /> in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.",INVESTIGATION AND EXPLORATION,, 7818,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?)"", 'have to embed <references /> in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",WORKAROUND,, 7818,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?)"", 'have to embed <references /> in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?),ISSUE CONTENT MANAGEMENT,, 7818,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",1373762484,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #7) > I don't understand what you're saying? This is an enhancement about users > frequently using a template to achieve a trivial software feature, and so > building that into reference lists (<references />s) rather than having them > need to invent and use the template. > > Reference incidences (<ref>s) inside templates are an entirely distinct > problem > for VisualEditor to worry about, and this isn't about that. :-) This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.","(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE This bug seems to be about enhancing <references /> so people won't (often?) have to embed <references /> in templates. However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template. The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group. As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis bug seems to be about enhancing <references /> so people won't (often?)"", 'have to embed <references /> in templates.', ""However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template."", 'The example Bartosz gave (Carles Puyol) boils down (after a few template layers) to [[pl:Szablon:Infobox_uwagi_dodaj]], which has its own references tag with a custom infobox group.', 'As shown at [[pl:Carles Puyol]], the effect is a small notes list just for the infobox.']",NA,0,"However, I think db's point is that there are other reasons (besides {{reflist}}) that <references /> may be in a template.",SOLUTION DISCUSSION,, 7819,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): https://pt.wikipedia.org/wiki/Template:Refer<65><72>ncias",1373746711,PHID-USER-sryrz6tgcfnnsiddx32p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): https://pt.wikipedia.org/wiki/Template:Refer<65><72>ncias","(In reply to comment #3) QUOTE QUOTE Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed.', 'The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...):\nURL']",NA,0,(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed.,SOCIAL CONVERSATION,, 7819,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): https://pt.wikipedia.org/wiki/Template:Refer<65><72>ncias",1373746711,PHID-USER-sryrz6tgcfnnsiddx32p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): https://pt.wikipedia.org/wiki/Template:Refer<65><72>ncias","(In reply to comment #3) QUOTE QUOTE Indeed. The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...): URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIndeed.', 'The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...):\nURL']",NA,0,"The equivalent template on Portuguese Wikipedia is also used to generate the header, and also has parameters to change the header text as well as its level (<h2>, <h3>, ...):\nURL",INVESTIGATION AND EXPLORATION,, 7820,Support editing <references /> tags to set multi-column display on/off,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.",SOLUTION DISCUSSION,, 7820,Support editing <references /> tags to set multi-column display on/off,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,Needs a set up a class for list-styles.,SOLUTION DISCUSSION,, 7820,Support editing <references /> tags to set multi-column display on/off,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".",SOLUTION DISCUSSION,, 7820,Support editing <references /> tags to set multi-column display on/off,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.",INVESTIGATION AND EXPLORATION,, 7820,Support editing <references /> tags to set multi-column display on/off,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",1373744313,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.","The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced. Needs a set up a class for list-styles. The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"". Thats why you can already add .references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; } to your common.css/user.css and all references will have column width, no need to tag each references tag with its own class. But the template has the advanced, that syntax errors will not eat the rest of the page.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['The references tag should support html attributes, than you can write <references class=""***"" /> and the template can be replaced.', 'Needs a set up a class for list-styles.', 'The extra class=""reflist"" is unneeded, because the references tag already adds class=""references"".', 'Thats why you can already add\n\n.references { column-width: 35em; -moz-column-width: 35em; -webkit-column-width: 35em; }\n\nto your common.css/user.css and all references will have column width, no need to tag each references tag with its own class.', 'But the template has the advanced, that syntax errors will not eat the rest of the page.']",NA,0,"But the template has the advanced, that syntax errors will not eat the rest of the page.",INVESTIGATION AND EXPLORATION,, 7821,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5) QUOTE QUOTE QUOTE I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template.', ""Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,"This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template.",ISSUE CONTENT MANAGEMENT,, 7821,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5) QUOTE QUOTE QUOTE I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template.', ""Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,:-),SOCIAL CONVERSATION,, 7821,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5) QUOTE QUOTE QUOTE I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template.', ""Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?,SOCIAL CONVERSATION,, 7821,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",1373724517,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)","(In reply to comment #5) QUOTE QUOTE QUOTE I don't understand what you're saying? This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template. Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI don't understand what you're saying?"", 'This is an enhancement about users frequently using a template to achieve a trivial software feature, and so building that into reference lists (<references />s) rather than having them need to invent and use the template.', ""Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that."", ':-)']",NA,0,"Reference incidences (<ref>s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that.",POTENTIAL NEW ISSUES AND REQUESTS,, 7822,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. Hm, yeah, I didn't think about it, but some infoboxes include their own <ref>s *and* <references group=.../>, for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].",1373709172,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #5) > You will become also problems with <ref> in infobox templates or so on, that > means you need another soluation than add a new tag or maintain a hardcoded > template list in VisualEditor. Hm, yeah, I didn't think about it, but some infoboxes include their own <ref>s *and* <references group=.../>, for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].","(In reply to comment #5) QUOTE QUOTE QUOTE Hm, yeah, I didn't think about it, but some infoboxes include their own <ref>s *and* <references group=.../>, for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nHm, yeah, I didn't think about it, but some infoboxes include their own <ref>s *and* <references group=.../>, for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].""]",NA,0,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nHm, yeah, I didn't think about it, but some infoboxes include their own <ref>s *and* <references group=.../>, for example pl.wp infoboxes for football players and some other sportsmen; an example can be seen on [[pl:Carles Puyol]].",SOLUTION DISCUSSION,, 7823,Support editing <references /> tags to set multi-column display on/off,"You will become also problems with <ref> in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.",1373700015,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"You will become also problems with <ref> in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.","You will become also problems with <ref> in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['You will become also problems with <ref> in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.']",NA,0,"You will become also problems with <ref> in infobox templates or so on, that means you need another soluation than add a new tag or maintain a hardcoded template list in VisualEditor.",SOLUTION DISCUSSION,, 7824,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. > > (In reply to comment #2) > > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > > browser figure out the layout makes more sense than hardcoded number > > > (although sadly it's not how it's done right now). > > > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > > not a graphical layout language, and should not be bastardised to serve as > > such. > > Hardcoding the number of columns is the same, except worse, since it can't be > adjusted to the capabilities of the browser/device without violating CSS > spec. > > CSS only allows specifying column width ""hints"", anyway, and they can be > measured in ems. > https://developer.mozilla.org/en-US/docs/Web/CSS/column-width OK, then I suppose we should maintain equivalence with {{reflist}} here.",1373665020,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #3) > Also, some wikis include more stuff in their reflist-like templates; for > example [[pl:Template:Przypisy]] unconditionally includes the heading. > > (In reply to comment #2) > > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > > browser figure out the layout makes more sense than hardcoded number > > > (although sadly it's not how it's done right now). > > > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > > not a graphical layout language, and should not be bastardised to serve as > > such. > > Hardcoding the number of columns is the same, except worse, since it can't be > adjusted to the capabilities of the browser/device without violating CSS > spec. > > CSS only allows specifying column width ""hints"", anyway, and they can be > measured in ems. > https://developer.mozilla.org/en-US/docs/Web/CSS/column-width OK, then I suppose we should maintain equivalence with {{reflist}} here.","(In reply to comment #3) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE OK, then I suppose we should maintain equivalence with {{reflist}} here.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nOK, then I suppose we should maintain equivalence with {{reflist}} here.']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nOK, then I suppose we should maintain equivalence with {{reflist}} here.",SOLUTION DISCUSSION,, 7825,Support editing <references /> tags to set multi-column display on/off,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.",SOLUTION USAGE,, 7825,Support editing <references /> tags to set multi-column display on/off,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.",SOLUTION DISCUSSION,, 7825,Support editing <references /> tags to set multi-column display on/off,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,URL,NA,X, 7825,Support editing <references /> tags to set multi-column display on/off,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width",1373664227,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > > browser figure out the layout makes more sense than hardcoded number (although > > sadly it's not how it's done right now). > > We should be reducing, not increasing, the use of hard-coded widths. HTML is > not a graphical layout language, and should not be bastardised to serve as > such. Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. https://developer.mozilla.org/en-US/docs/Web/CSS/column-width","Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading. (In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Hardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec. CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems. URL",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Also, some wikis include more stuff in their reflist-like templates; for example [[pl:Template:Przypisy]] unconditionally includes the heading.', ""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec."", 'CSS only allows specifying column width ""hints"", anyway, and they can be measured in ems.', 'URL']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nHardcoding the number of columns is the same, except worse, since it can't be adjusted to the capabilities of the browser/device without violating CSS spec.",SOLUTION DISCUSSION,, 7826,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.",SOLUTION DISCUSSION,, 7826,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"HTML is not a graphical layout language, and should not be bastardised to serve as such.",SOLUTION DISCUSSION,X, 7826,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",1373663834,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #1) > (In reply to comment #0) > > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > > allowing width, obviously) > > ""Obviously""? In my opinion setting maximalcolumn width and letting the > browser figure out the layout makes more sense than hardcoded number (although > sadly it's not how it's done right now). We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. > > * list-style (default to decimal; just an escaped pass-through of the CSS > > list-style of the OL) > > That would be a bad way to do this; the list style should actually depends on > the group name used (since Cite has a way to provide custom markers instead > of [1] to reference citations, list-style is used to match them - see > [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on > en.wp). Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE We should be reducing, not increasing, the use of hard-coded widths. HTML is not a graphical layout language, and should not be bastardised to serve as such. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Sorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWe should be reducing, not increasing, the use of hard-coded widths.', 'HTML is not a graphical layout language, and should not be bastardised to serve as such.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".']",NA,0,"QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nSorry, yes, I meant ""default to what the group states; if no group, default to decimal; otherwise, let the user over-ride"".",SOLUTION DISCUSSION,, 7827,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0) QUOTE QUOTE ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). QUOTE QUOTE That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?",SOCIAL CONVERSATION,, 7827,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0) QUOTE QUOTE ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). QUOTE QUOTE That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,"QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",SOLUTION DISCUSSION,, 7827,Support editing <references /> tags to set multi-column display on/off,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",1373663426,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-p6rccw5cwglxrbbkmq2b,task_subcomment,"(In reply to comment #0) > * columns (default to 1; a number between 1 and <20><><EFBFBD> another number? - not > allowing width, obviously) ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). > * list-style (default to decimal; just an escaped pass-through of the CSS > list-style of the OL) That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).","(In reply to comment #0) QUOTE QUOTE ""Obviously""? In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now). QUOTE QUOTE That would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\n""Obviously""?', ""In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now)."", 'QUOTE\nQUOTE\n\nThat would be a bad way to do this; the list style should actually depends on the group name used (since Cite has a way to provide custom markers instead of [1] to reference citations, list-style is used to match them - see [[Special:PrefixIndex/MediaWiki:Cite_link_label_group]] for ones defined on en.wp).']",NA,0,In my opinion setting maximalcolumn width and letting the browser figure out the layout makes more sense than hardcoded number (although sadly it's not how it's done right now).,SOLUTION DISCUSSION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.",OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.",OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,I fetched the Parsoid extension by using git.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .",OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.",OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,I installed that.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,"net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)",OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,And the remaining installation process are with no error.,BUG REPRODUCTION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,Debug options is uncommented.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,Others remain the same.,SOCIAL CONVERSATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,That is all I have done to the whole Parsoid.,INVESTIGATION AND EXPLORATION,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC,OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig.,OBSERVED BUG BEHAVIOR,, 7882,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",1373507520,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_description,"Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** `stephdechine` **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but http://localhost:8000/en/Main_Page does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC","Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig./n/n**Author:** CODE **Description:** I have just installed Parsoid for my private MediaWiki. However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500. Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out. TypeError: Cannot set property '0' of null at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29) at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16) at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22) at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2) at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11) at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11) at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5) at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5) at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10) at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15) My OS is Gentoo Linux with everything up-to-date. I fetched the Parsoid extension by using git. I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure . Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm. I installed that. net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13) (masked by default, I unmasked that.) And the remaining installation process are with no error. I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address. Debug options is uncommented. Others remain the same. That is all I have done to the whole Parsoid. -------------------------- **Version**: unspecified **Severity**: normal **OS**: Linux **Platform**: PC",Medium,50,1373610519,NA,declined,TRUE,c1,3,FALSE,FALSE,1,NA,"[""Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig."", '**Author:** CODE\n\n**Description:**\nI have just installed Parsoid for my private MediaWiki.', 'However when I try to use VisualEditor, I got parsoidserver-http-bad-status: 500.', 'Then I had checked localhost:8000, and that page displays correctly, but URL does not work as expected, and some error messages are thrown out.', ""TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date."", 'I fetched the Parsoid extension by using git.', 'I have once tried to install nodejs by compiling the source code, but failed due to ""Syntax error"" when running ./configure .', 'Then I had checked my OS repo, and found out that there is only net-libs/nodejs with no npm.', 'I installed that.', 'net-libs/nodejs Installed versions: 0.10.8^t(19:04:51 07/10/13)\n(masked by default, I unmasked that.)', 'And the remaining installation process are with no error.', 'I copied the api/localsettings.js.example to api/localsettings.js and changed the localhost to the IP address.', 'Debug options is uncommented.', 'Others remain the same.', 'That is all I have done to the whole Parsoid.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC']",TRUE,0,TypeError: Cannot set property '0' of null\n at Object.WikiConfig (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:52:29)\n at Function.MWParserEnvironment.getParserEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:268:16)\n at getParserServiceEnv (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:365:22)\n at app.post.oldid (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/api/ParserService.js:629:2)\n at callbacks (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:272:11)\n at param (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:246:11)\n at pass (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:253:5)\n at Router._dispatch (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:280:5)\n at Object.Router.middleware [as handle] (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/lib/router/index.js:45:10)\n at next (/var/www/localhost/htdocs/wiki/extensions/Parsoid/js/node_modules/express/node_modules/connect/lib/http.js:204:15)\n\nMy OS is Gentoo Linux with everything up-to-date.,BUG REPRODUCTION,, 7883,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote: (In reply to comment #2) QUOTE QUOTE QUOTE Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.,SOCIAL CONVERSATION,, 7883,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote: (In reply to comment #2) QUOTE QUOTE QUOTE Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,After I downgrade node.js to 0.8.23 everything works correctly.,WORKAROUND,, 7883,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote: (In reply to comment #2) QUOTE QUOTE QUOTE Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,My fault.,SOCIAL CONVERSATION,, 7883,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",1373610519,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"**stephdechine** wrote: (In reply to comment #2) > I also see that you are using Node 0.10.8. Note that currently Parsoid only > supports node 0.8 > (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10) Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.","**stephdechine** wrote: (In reply to comment #2) QUOTE QUOTE QUOTE Thank you for pointing out that. After I downgrade node.js to 0.8.23 everything works correctly. My fault. That works for me.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**stephdechine** wrote:\n\n(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nThank you for pointing out that.', 'After I downgrade node.js to 0.8.23 everything works correctly.', 'My fault.', 'That works for me.']",NA,0,That works for me.,SOCIAL CONVERSATION,, 7884,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10),1373558667,PHID-USER-slccyo5rqasgpljxny7g,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10),I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (URL,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['I also see that you are using Node 0.10.8.', 'Note that currently Parsoid only supports node 0.8 (URL']",NA,0,I also see that you are using Node 0.10.8.,SOCIAL CONVERSATION,, 7884,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10),1373558667,PHID-USER-slccyo5rqasgpljxny7g,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (http://www.mediawiki.org/wiki/Parsoid#Use_node.js_0.8.2C_not_0.10),I also see that you are using Node 0.10.8. Note that currently Parsoid only supports node 0.8 (URL,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['I also see that you are using Node 0.10.8.', 'Note that currently Parsoid only supports node 0.8 (URL']",NA,0,Note that currently Parsoid only supports node 0.8 (URL,INVESTIGATION AND EXPLORATION,, 7885,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl <yourApiURL>\n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,Your wiki API is not reachable from the Parsoid machine.,INVESTIGATION AND EXPLORATION,, 7885,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl <yourApiURL>\n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,"Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.",INVESTIGATION AND EXPLORATION,, 7885,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl <yourApiURL>\n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,Example commandline:\n\ncurl <yourApiURL>\n\nWe should probably print this information when the config request fails.,POTENTIAL NEW ISSUES AND REQUESTS,, 7885,Print helpful 'your API is not reachable' message instead of TypeError: Cannot set property '0' of null at Object.WikiConfig,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",1373556483,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-l5pjiw32hngnewgrmmmy,task_subcomment,"Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.","Your wiki API is not reachable from the Parsoid machine. Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice. Example commandline: curl <yourApiURL> We should probably print this information when the config request fails. Repurposing this bug for that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,1,NA,"['Your wiki API is not reachable from the Parsoid machine.', 'Configure it correctly in localsettings.js and verify that it is indeed reachable using wget, curl, w3m or any other tool of your choice.', 'Example commandline:\n\ncurl <yourApiURL>\n\nWe should probably print this information when the config request fails.', 'Repurposing this bug for that.']",NA,0,Repurposing this bug for that.,ACTION ON ISSUE,, 9997,[mediawiki.feedback.js] Feedback should follow redirect,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",1366979940,PHID-USER-hoj4lurwi6bejyjy5qlp,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_description,"[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1419984894,PHID-USER-wkpnidxoctuhawexig5p,resolved,TRUE,c1,1,FALSE,FALSE,-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,[mediawiki.feedback.js] Feedback should follow redirect.,EXPECTED BEHAVIOR,, 9997,[mediawiki.feedback.js] Feedback should follow redirect,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",1366979940,PHID-USER-hoj4lurwi6bejyjy5qlp,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_description,"[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1419984894,PHID-USER-wkpnidxoctuhawexig5p,resolved,TRUE,c1,1,FALSE,FALSE,-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,Is that even the correct message to change?,INVESTIGATION AND EXPLORATION,, 9997,[mediawiki.feedback.js] Feedback should follow redirect,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",1366979940,PHID-USER-hoj4lurwi6bejyjy5qlp,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_description,"[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1419984894,PHID-USER-wkpnidxoctuhawexig5p,resolved,TRUE,c1,1,FALSE,FALSE,-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.",OBSERVED BUG BEHAVIOR,, 9997,[mediawiki.feedback.js] Feedback should follow redirect,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",1366979940,PHID-USER-hoj4lurwi6bejyjy5qlp,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_description,"[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1419984894,PHID-USER-wkpnidxoctuhawexig5p,resolved,TRUE,c1,1,FALSE,FALSE,-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 9997,[mediawiki.feedback.js] Feedback should follow redirect,"I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",1366979940,PHID-USER-hoj4lurwi6bejyjy5qlp,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_description,"[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement","[mediawiki.feedback.js] Feedback should follow redirect./n/nI tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all. Is that even the correct message to change? I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect. -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1419984894,PHID-USER-wkpnidxoctuhawexig5p,resolved,TRUE,c1,1,FALSE,FALSE,-10,NA,"['[mediawiki.feedback.js] Feedback should follow redirect.', ""I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all."", 'Is that even the correct message to change?', 'I then turn the target page into a redirect, but feedback are still sent to that page without following the redirect.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't affect the feedback target page at all.,OBSERVED BUG BEHAVIOR,, 9998,[mediawiki.feedback.js] Feedback should follow redirect,Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (https://gerrit.wikimedia.org/r/#/c/143171/).,1419984894,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_subcomment,Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (https://gerrit.wikimedia.org/r/#/c/143171/).,Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,78,NA,['Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL'],NA,0,Fixed in 96c4e453ecfaba9cc5dca904301981e9d6e3492b (URL,TASK PROGRESS,, 9999,[mediawiki.feedback.js] Feedback should follow redirect,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_subcomment,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0) QUOTE QUOTE QUOTE Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - URL [1] - URL QUOTE QUOTE You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).",SOLUTION USAGE,, 9999,[mediawiki.feedback.js] Feedback should follow redirect,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_subcomment,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0) QUOTE QUOTE QUOTE Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - URL [1] - URL QUOTE QUOTE You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,Moving the bug there.,ACTION ON ISSUE,, 9999,[mediawiki.feedback.js] Feedback should follow redirect,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",1366986213,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-xjswbfq6vvdy4oyl6qub,task_subcomment,"(In reply to comment #0) > I tried to edit MediaWiki:Visualeditor-feedback-link on zhwp but it doesn't > affect the feedback target page at all. Is that even the correct message to > change? Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hans&group=ext-visualeditor [1] - https://translatewiki.net/w/i.php?title=Special:Translate&language=zh-hant&group=ext-visualeditor > I then turn the target page into a redirect, but feedback are still sent to > that page without following the redirect. You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.","(In reply to comment #0) QUOTE QUOTE QUOTE Yes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated). [0] - URL [1] - URL QUOTE QUOTE You're right; this is a bug in the feedback tool, which is part of MediaWiki core. Moving the bug there.",NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-10,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nYes, that is the correct message; you can set it for all zh-hans or zh-hant projects at [0] and [1] and it will respect it (once the software is updated).', ""[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core."", 'Moving the bug there.']",NA,0,"[0] - URL\n[1] - URL\n\nQUOTE\nQUOTE\n\nYou're right; this is a bug in the feedback tool, which is part of MediaWiki core.",INVESTIGATION AND EXPLORATION,X, 10214,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",1359492240,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_description,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1382479475,NA,resolved,TRUE,c1,1,TRUE,FALSE,-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,[Very much a longer-term enhancement.],FUTURE PLANS,, 10214,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",1359492240,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_description,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1382479475,NA,resolved,TRUE,c1,1,TRUE,FALSE,-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 10214,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",1359492240,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_description,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1382479475,NA,resolved,TRUE,c1,1,TRUE,FALSE,-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,Parsoid should support passing on an authenticated user's read right (when MW API supports that).,EXPECTED BEHAVIOR,, 10214,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",1359492240,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_description,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n[Very much a longer-term enhancement.] Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet). -------------------------- **Version**: unspecified **Severity**: enhancement",Medium,50,1382479475,NA,resolved,TRUE,c1,1,TRUE,FALSE,-22,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '[Very much a longer-term enhancement.]', ""Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet)."", '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,Parsoid doesn't currently have support for passing on an authenticated user's read right when fetching the wikitext (because the API doesn't support that yet).,OBSERVED BUG BEHAVIOR,, 10215,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Change 91111 merged by jenkins-bot: Support private wikis by forwarding Cookie: headers to Parsoid https://gerrit.wikimedia.org/r/91111",1383678031,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Change 91111 merged by jenkins-bot: Support private wikis by forwarding Cookie: headers to Parsoid https://gerrit.wikimedia.org/r/91111","Change 91111 merged by jenkins-bot: Support private wikis by forwarding Cookie: headers to Parsoid GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,['Change 91111 merged by jenkins-bot:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL'],NA,0,Change 91111 merged by jenkins-bot:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL,TASK PROGRESS,, 10216,Parsoid should support passing on an authenticated user's read right (when MW API supports that),Closing again.,1382479475,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,Closing again.,Closing again.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,16,NA,['Closing again.'],NA,0,Closing again.,ACTION ON ISSUE,, 10217,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Change 91111 had a related patch set uploaded by Jforrester: Support private wikis by forwarding Cookie: headers to Parsoid https://gerrit.wikimedia.org/r/91111",1382404256,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Change 91111 had a related patch set uploaded by Jforrester: Support private wikis by forwarding Cookie: headers to Parsoid https://gerrit.wikimedia.org/r/91111","Change 91111 had a related patch set uploaded by Jforrester: Support private wikis by forwarding Cookie: headers to Parsoid GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,16,NA,['Change 91111 had a related patch set uploaded by Jforrester:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL'],NA,0,Change 91111 had a related patch set uploaded by Jforrester:\nSupport private wikis by forwarding Cookie: headers to Parsoid\n\nGERRIT_URL,TASK PROGRESS,, 10218,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,"Cookies are now forwarded, and caching is disabled if a cookie is set.",SOLUTION DISCUSSION ,, 10218,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,Closing this bug as fixed.,ACTION ON ISSUE,, 10218,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",1381966182,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.","Cookies are now forwarded, and caching is disabled if a cookie is set. Closing this bug as fixed. A content API will have to do its own auth.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,15,NA,"['Cookies are now forwarded, and caching is disabled if a cookie is set.', 'Closing this bug as fixed.', 'A content API will have to do its own auth.']",NA,0,A content API will have to do its own auth.,SOLUTION DISCUSSION,, 10219,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Change 85414 merged by jenkins-bot: Bug 44483: Forward Cookie header to API https://gerrit.wikimedia.org/r/85414",1381965890,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Change 85414 merged by jenkins-bot: Bug 44483: Forward Cookie header to API https://gerrit.wikimedia.org/r/85414","Change 85414 merged by jenkins-bot: Bug 44483: Forward Cookie header to API GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,15,NA,['Change 85414 merged by jenkins-bot:\nBug 44483: Forward Cookie header to API\n\nGERRIT_URL'],NA,0,Change 85414 merged by jenkins-bot:\nBug 44483: Forward Cookie header to API\n\nGERRIT_URL,TASK PROGRESS,, 10220,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,"Parsoid might not even be involved in that case, only the content API / storage is.",INVESTIGATION AND EXPLORATION,, 10220,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,See URL for the current WIP on that.,ISSUE CONTENT MANAGEMENT,, 10220,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.",1381260438,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"(In reply to comment #4) > Random idea: > > Could Parsoid be made private (already is, though last I checked it still > has a > public IP) and use an internal API instead of the public API. Then the > responsibility for user rights lays in MediaWiki land, and when the request > is > in Parsoid we can assume it is authenticated and thus Parsoid can have > unrestricted access. That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage for the current WIP on that.","(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE That is what we'll have to do in the longer term once we store HTML. Parsoid might not even be involved in that case, only the content API / storage is. See URL for the current WIP on that.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML."", 'Parsoid might not even be involved in that case, only the content API / storage is.', 'See URL for the current WIP on that.']",NA,0,(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is what we'll have to do in the longer term once we store HTML.,FUTURE PLANS,, 10221,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",1380024239,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.","Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API.', 'Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.']",NA,0,"Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API.",SOLUTION DISCUSSION ,, 10221,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",1380024239,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.","Random idea: Could Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API. Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,12,NA,"['Random idea:\n\nCould Parsoid be made private (already is, though last I checked it still has a public IP) and use an internal API instead of the public API.', 'Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.']",NA,0,"Then the responsibility for user rights lays in MediaWiki land, and when the request is in Parsoid we can assume it is authenticated and thus Parsoid can have unrestricted access.",SOLUTION DISCUSSION,, 10222,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"Change 85414 had a related patch set uploaded by GWicke: WIP Bug 44483: Forward Cookie header to API https://gerrit.wikimedia.org/r/85414",1379754726,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,"Change 85414 had a related patch set uploaded by GWicke: WIP Bug 44483: Forward Cookie header to API https://gerrit.wikimedia.org/r/85414","Change 85414 had a related patch set uploaded by GWicke: WIP Bug 44483: Forward Cookie header to API GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,11,NA,['Change 85414 had a related patch set uploaded by GWicke:\nWIP Bug 44483: Forward Cookie header to API\n\nGERRIT_URL'],NA,0,Change 85414 had a related patch set uploaded by GWicke:\nWIP Bug 44483: Forward Cookie header to API\n\nGERRIT_URL,TASK PROGRESS,, 10223,Parsoid should support passing on an authenticated user's read right (when MW API supports that),*** Bug 44313 has been marked as a duplicate of this bug. ***,1360207511,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,*** Bug 44313 has been marked as a duplicate of this bug. ***,*** Bug 44313 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-21,NA,"['*** Bug 44313 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 44313 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 10223,Parsoid should support passing on an authenticated user's read right (when MW API supports that),*** Bug 44313 has been marked as a duplicate of this bug. ***,1360207511,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,*** Bug 44313 has been marked as a duplicate of this bug. ***,*** Bug 44313 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-21,NA,"['*** Bug 44313 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 10224,Parsoid should support passing on an authenticated user's read right (when MW API supports that),Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,1359588905,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-22,NA,"['Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this.', 'Definitely worth a try.']",NA,0,Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this.,SOLUTION DISCUSSION,, 10224,Parsoid should support passing on an authenticated user's read right (when MW API supports that),Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,1359588905,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-yycd32q4sp6a3jbmgdq4,task_subcomment,Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this. Definitely worth a try.,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-22,NA,"['Passing on the cookie header from the VisualEditor extension to Parsoid and then from Parsoid back to the API might be enough to enable this.', 'Definitely worth a try.']",NA,0,Definitely worth a try.,SOCIAL CONVERSATION,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".",INVESTIGATION AND EXPLORATION,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,When viewing an article you don\,INVESTIGATION AND EXPLORATION,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected.",OBSERVED BUG BEHAVIOR,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,view source,NA,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,view source,NA,, 11321,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",1374077880,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-qh3lrsa2vheyfhks3klm,task_description,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement","VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected./n/nWhen viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"". When viewing an article you don't have permission to edit, you see only one - ""view source"". This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!), see Bug 51547. If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means). -------------------------- **Version**: unspecified **Severity**: enhancement",Low,25,1385386552,NA,declined,TRUE,c1,3,FALSE,FALSE,2,NA,"[""VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected."", 'When viewing an article you have permission to edit, you see two tabs at the top - ""Edit"" and ""Edit source"".', 'When viewing an article you don\'t have permission to edit, you see only one - ""view source"".', 'This is not good UI design There needs to always be the same number of tabs displayed.', 'Ideally there should be tabs to ""view source"" and ""view visual source"" (with better wording though!', '), see Bug 51547.', 'If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,view visual source,NA,, 11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,PHID-USER-hphmqcx66p6d6gvmjzp7,PHID-TASK-qh3lrsa2vheyfhks3klm,task_subcomment,"Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,Comment...,SOCIAL CONVERSATION,, 11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,PHID-USER-hphmqcx66p6d6gvmjzp7,PHID-TASK-qh3lrsa2vheyfhks3klm,task_subcomment,"Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,"I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.",SOLUTION DISCUSSION,, 11322,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",1427495377,PHID-USER-hphmqcx66p6d6gvmjzp7,PHID-TASK-qh3lrsa2vheyfhks3klm,task_subcomment,"Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...","Comment... I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,90,NA,"['Comment...', 'I think it might be useful to have the suggested ""view visual source"" tab, primarily to enable copying content such as references between protected and non-protected articles.', 'However, I do grok the additional layers of complexity this would entail...']",NA,0,"However, I do grok the additional layers of complexity this would entail...",SOLUTION DISCUSSION,, 11323,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",1385386552,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-qh3lrsa2vheyfhks3klm,task_subcomment,"A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).","A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,21,NA,"['A ""read-only editor"" is the view mode<64><65><EFBFBD> I\'m not really sure there\'s much value in going down the route, but instead we\'d want to combine the two edit tabs together (except for users with VisualEditor disabled).']",NA,0,"A ""read-only editor"" is the view mode<64><65><EFBFBD> I\",WORKAROUND,, 11323,"VisualEditor: Show two editing/view source tabs at all times, even if you can't edit page because it's protected","A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",1385386552,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-qh3lrsa2vheyfhks3klm,task_subcomment,"A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).","A ""read-only editor"" is the view mode<64><65><EFBFBD> I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,21,NA,"['A ""read-only editor"" is the view mode<64><65><EFBFBD> I\'m not really sure there\'s much value in going down the route, but instead we\'d want to combine the two edit tabs together (except for users with VisualEditor disabled).']",NA,0,"s much value in going down the route, but instead we\",FUTURE PLANS,, 11568,Messing up Math formulas,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",1373289300,PHID-USER-joqqkabmjmvxeucx4ni2,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_description,"Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. URL URL URL I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1373592757,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Messing up Math formulas.,OBSERVED BUG BEHAVIOR,, 11568,Messing up Math formulas,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",1373289300,PHID-USER-joqqkabmjmvxeucx4ni2,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_description,"Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. URL URL URL I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1373592757,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.,OBSERVED BUG BEHAVIOR,, 11568,Messing up Math formulas,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",1373289300,PHID-USER-joqqkabmjmvxeucx4ni2,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_description,"Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. URL URL URL I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1373592757,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 11568,Messing up Math formulas,"Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",1373289300,PHID-USER-joqqkabmjmvxeucx4ni2,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_description,"Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441 https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206 https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797 I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal","Messing up Math formulas./n/nSeveral concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all. URL URL URL I'm not sure if this is related to an existing bug or a different kind of thing. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1373592757,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['Messing up Math formulas.', 'Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.', ""URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,URL\n\nURL\n\nURL\n\nI'm not sure if this is related to an existing bug or a different kind of thing.,INVESTIGATION AND EXPLORATION,, 11569,Messing up Math formulas,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.,ISSUE CONTENT MANAGEMENT,, 11569,Messing up Math formulas,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,It is a round tripping error in VisualEditor.,INVESTIGATION AND EXPLORATION,, 11569,Messing up Math formulas,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",1373592757,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%","**cbm.wikipedia** wrote: This is a duplicate of bug 50291. It is a round tripping error in VisualEditor. %%%*** This bug has been marked as a duplicate of bug 50291 ***%%%",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['**cbm.wikipedia** wrote:\n\nThis is a duplicate of bug 50291.', 'It is a round tripping error in VisualEditor.', '%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%']",NA,0,%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%,ACTION ON ISSUE,, 11570,Messing up Math formulas,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",1373290493,PHID-USER-7hrs7wwclcldf7mm6a7o,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,Just the way italics (used to mark variables) and superscript and subscript tags interact.,INVESTIGATION AND EXPLORATION,, 11570,Messing up Math formulas,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",1373290493,PHID-USER-7hrs7wwclcldf7mm6a7o,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,Marking as low priority as no visible change.,ACTION ON ISSUE,, 11570,Messing up Math formulas,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",1373290493,PHID-USER-7hrs7wwclcldf7mm6a7o,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,The changes don't actually change the visual output.,SOLUTION USAGE,, 11570,Messing up Math formulas,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",1373290493,PHID-USER-7hrs7wwclcldf7mm6a7o,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically.,SOLUTION DISCUSSION,, 11570,Messing up Math formulas,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",1373290493,PHID-USER-7hrs7wwclcldf7mm6a7o,PHID-TASK-tlllnzr2q3k5zu3yv6nh,task_subcomment,"The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.","The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically. Marking as low priority as no visible change.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"[""The changes don't actually change the visual output."", 'Just the way italics (used to mark variables) and superscript and subscript tags interact.', ""So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically."", ""Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically."", 'Marking as low priority as no visible change.']",NA,0,"Other cases will split a complex superscript into two separate subscripts ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically.",SOLUTION DISCUSSION ,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,VisualEditor: Transclusions editor should support parser functions and variables.,EXPECTED BEHAVIOR,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.",OBSERVED BUG BEHAVIOR,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,This makes it impossible to edit expr1 in VE.,INVESTIGATION AND EXPLORATION,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,Same for parserfunctions like urlencode and template messages.,OBSERVED BUG BEHAVIOR,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.",EXPECTED BEHAVIOR,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,"Until we can, we should show an explanatory message when the user attempts to add one.",SOLUTION DISCUSSION,, 11649,VisualEditor: Transclusions editor should support parser functions and variables,"Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",1373104140,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-5tthiu6szwn225okbzla,task_description,"VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}","VisualEditor: Transclusions editor should support parser functions and variables./n/nParser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}} Currently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc. This makes it impossible to edit expr1 in VE. Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. **See also:** {T54607}",Low,25,NA,NA,open,TRUE,c1,3,TRUE,FALSE,0,NA,"['VisualEditor: Transclusions editor should support parser functions and variables.', 'Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}\n\nCurrently VE sees this as a template with name ""#function_name : expr1"" and arguments ""1 = expr2"", ""2 = expr3"", etc.', 'This makes it impossible to edit expr1 in VE.', 'Same for parserfunctions like urlencode and template messages.', 'The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode.', 'Until we can, we should show an explanatory message when the user attempts to add one.', '**See also:**\n{T54607}']",FALSE,0,**See also:**\n{T54607},ISSUE CONTENT MANAGEMENT,, 11650,VisualEditor: Transclusions editor should support parser functions and variables,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,PHID-USER-wmk4bsljm5c77zhckwcj,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,So yeah.,SOCIAL CONVERSATION,, 11650,VisualEditor: Transclusions editor should support parser functions and variables,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,PHID-USER-wmk4bsljm5c77zhckwcj,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,Matma Rex has merged T249860 with this task.,TASK PROGRESS,, 11650,VisualEditor: Transclusions editor should support parser functions and variables,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].",1587917120,PHID-USER-wmk4bsljm5c77zhckwcj,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor | Wikipedia:VisualEditor ]].","So yeah. Matma Rex has merged T249860 with this task. Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,355,NA,"['So yeah.', 'Matma Rex has merged T249860 with this task.', 'Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].']",NA,0,"Also, I will add details about this task on [[ URL | Wikipedia:VisualEditor ]].",CONTRIBUTION AND COMMITMENT,, 11651,VisualEditor: Transclusions editor should support parser functions and variables,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",1435260148,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,103,NA,"[""If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g."", '{{# is never a template) or comparing it to a list of parser functions?']",NA,0,{{# is never a template) or comparing it to a list of parser functions?,SOLUTION DISCUSSION,, 11651,VisualEditor: Transclusions editor should support parser functions and variables,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",1435260148,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?","If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,103,NA,"[""If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g."", '{{# is never a template) or comparing it to a list of parser functions?']",NA,0,"If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g.",SOLUTION DISCUSSION,, 11652,VisualEditor: Transclusions editor should support parser functions and variables,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",1373465761,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace.', 'For example {{formatnum:...}} is probably used a lot there.']",NA,0,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace.",INVESTIGATION AND EXPLORATION,, 11652,VisualEditor: Transclusions editor should support parser functions and variables,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",1373465761,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.","Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,1,NA,"['Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace.', 'For example {{formatnum:...}} is probably used a lot there.']",NA,0,For example {{formatnum:...}} is probably used a lot there.,INVESTIGATION AND EXPLORATION,, 11653,VisualEditor: Transclusions editor should support parser functions and variables,"Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.",1373160763,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-5tthiu6szwn225okbzla,task_subcomment,"Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.","Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,0,NA,"[""Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.""]",NA,0,"Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.",INVESTIGATION AND EXPLORATION,, 11748,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-wzei4tpax7kpf3oq25mp,task_description,"VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Low,25,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,0,NA,"['VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).,EXPECTED BEHAVIOR,, 11748,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-wzei4tpax7kpf3oq25mp,task_description,"VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Low,25,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,0,NA,"['VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.,OBSERVED BUG BEHAVIOR,, 11748,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-wzei4tpax7kpf3oq25mp,task_description,"VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Low,25,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,0,NA,"['VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,You then have to follow the link (which is hard in edit mode) and go looking again.,OBSERVED BUG BEHAVIOR,, 11748,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-wzei4tpax7kpf3oq25mp,task_description,"VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Low,25,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,0,NA,"['VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.",MOTIVATION,, 11748,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208",1372786320,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-wzei4tpax7kpf3oq25mp,task_description,"VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=59208","VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups)./n/nDisambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again. Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Low,25,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,resolved,TRUE,c1,3,FALSE,FALSE,0,NA,"['VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups).', 'Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right.', 'You then have to follow the link (which is hard in edit mode) and go looking again.', 'Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 11749,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),This is effectively now solved with the link image/data preview,1431047236,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,This is effectively now solved with the link image/data preview,This is effectively now solved with the link image/data preview,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,96,NA,['This is effectively now solved with the link image/data preview'],NA,0,This is effectively now solved with the link image/data preview,TASK PROGRESS,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.",SOLUTION USAGE,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?,INVESTIGATION AND EXPLORATION,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,Is [[AC/DC]] leading to an article about electrical engineering or about a band?,INVESTIGATION AND EXPLORATION,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.",SOLUTION USAGE,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"(Although reusing the Hovercards code makes sense, too.)",WORKAROUND,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"It probably shouldn't be the highest priority, but as an editor, I would like something like this.",MOTIVATION,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,"In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards.",MOTIVATION,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,So I would love to see something more than just the title when I'm linking.,MOTIVATION,, 11750,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",1401698735,PHID-USER-xfe43w2lb5gpvglf4coa,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)","It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure. So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,48,NA,"[""It probably shouldn't be the highest priority, but as an editor, I would like something like this."", ""In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards."", 'As I am editing, however, it would be useful for me to add a link and be more sure as to where is the link leading.', 'Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album?', 'Is [[AC/DC]] leading to an article about electrical engineering or about a band?', 'These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.', ""So I would love to see something more than just the title when I'm linking."", ""It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough."", '(Although reusing the Hovercards code makes sense, too.)']",NA,0,It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough.,SOLUTION DISCUSSION,, 11751,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",1377023920,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"[""I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then."", ""Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.""]",NA,0,"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then.",ISSUE CONTENT MANAGEMENT,, 11751,VisualEditor: Link inspector should preview the linked page (<28><> la Navigation Popups),"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",1377023920,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wzei4tpax7kpf3oq25mp,task_subcomment,"I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.","I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"[""I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then."", ""Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.""]",NA,0,"Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.",SOLUTION DISCUSSION,, 12509,VisualEditor: Add static name property to CE nodes,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",1362405720,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_description,"VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1362705677,NA,resolved,TRUE,c1,1,TRUE,FALSE,-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,VisualEditor: Add static name property to CE nodes.,SOLUTION DISCUSSION,, 12509,VisualEditor: Add static name property to CE nodes,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",1362405720,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_description,"VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1362705677,NA,resolved,TRUE,c1,1,TRUE,FALSE,-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,DM nodes have a static name property which is used by the nodeRegistry.,INVESTIGATION AND EXPLORATION,, 12509,VisualEditor: Add static name property to CE nodes,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",1362405720,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_description,"VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1362705677,NA,resolved,TRUE,c1,1,TRUE,FALSE,-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,CE nodes currently have their names written out at least twice.,OBSERVED BUG BEHAVIOR,, 12509,VisualEditor: Add static name property to CE nodes,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",1362405720,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_description,"VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1362705677,NA,resolved,TRUE,c1,1,TRUE,FALSE,-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 12509,VisualEditor: Add static name property to CE nodes,"DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",1362405720,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_description,"VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal","VisualEditor: Add static name property to CE nodes./n/nDM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded). -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1362705677,NA,resolved,TRUE,c1,1,TRUE,FALSE,-17,NA,"['VisualEditor: Add static name property to CE nodes.', 'DM nodes have a static name property which is used by the nodeRegistry.', 'CE nodes currently have their names written out at least twice.', ""It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded)."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).,OBSERVED BUG BEHAVIOR,, 12510,VisualEditor: Add static name property to CE nodes,Related URL: https://gerrit.wikimedia.org/r/52545 (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7),1362697441,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/52545 (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7),Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7),NA,NA,NA,NA,NA,TRUE,c1,1,FALSE,NA,-17,NA,['Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)'],NA,0,Related URL: GERRIT_URL (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7),ISSUE CONTENT MANAGEMENT,, 12511,VisualEditor: Add static name property to CE nodes,Fixed with https://gerrit.wikimedia.org/r/#/c/52545/,1362610508,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-qrmj2zvtj5xzsxn37rp3,task_subcomment,Fixed with https://gerrit.wikimedia.org/r/#/c/52545/,Fixed with URL,NA,NA,NA,NA,NA,TRUE,c1,1,TRUE,NA,-17,NA,['Fixed with URL'],NA,0,Fixed with URL,TASK PROGRESS,, 13645,Flow: SSL error on email notifications,"Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",1382995560,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-tdujfoz6otc4aeopydss,task_description,"Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1383175363,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,Flow: SSL error on email notifications.,OBSERVED BUG BEHAVIOR,, 13645,Flow: SSL error on email notifications,"Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",1382995560,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-tdujfoz6otc4aeopydss,task_description,"Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1383175363,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: master\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 13645,Flow: SSL error on email notifications,"Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",1382995560,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-tdujfoz6otc4aeopydss,task_description,"Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal","Flow: SSL error on email notifications./n/nVisit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error. -------------------------- **Version**: master **Severity**: normal",Needs Triage,90,1383175363,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Flow: SSL error on email notifications.', ""Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,Visit a link in an email notification for a Flow event <20><><EFBFBD> you'll receive an SSL error.,OBSERVED BUG BEHAVIOR,, 13646,Flow: SSL error on email notifications,"**bsitu** wrote: solved by configuring the server",1383175363,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tdujfoz6otc4aeopydss,task_subcomment,"**bsitu** wrote: solved by configuring the server","**bsitu** wrote: solved by configuring the server",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,9,TRUE,['**bsitu** wrote:\n\nsolved by configuring the server'],NA,0,**bsitu** wrote:\n\nsolved by configuring the server,TASK PROGRESS,, 13647,Flow: SSL error on email notifications,"**bsitu** wrote: same for the following code: global $wgServer; echo $wgServer; http://ee-flow.wmflabs.org vs //ee-flow.wmflabs.org",1383160996,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tdujfoz6otc4aeopydss,task_subcomment,"**bsitu** wrote: same for the following code: global $wgServer; echo $wgServer; http://ee-flow.wmflabs.org vs //ee-flow.wmflabs.org","**bsitu** wrote: same for the following code: global $wgServer; echo $wgServer; URL vs //ee-flow.wmflabs.org",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,9,TRUE,['**bsitu** wrote:\n\nsame for the following code:\n\nglobal $wgServer;\necho $wgServer;\n\n\nURL vs //ee-flow.wmflabs.org'],NA,0,**bsitu** wrote:\n\nsame for the following code:\n\nglobal $wgServer;\necho $wgServer;\n\n\nURL vs //ee-flow.wmflabs.org,BUG REPRODUCTION,, 13648,Flow: SSL error on email notifications,"**bsitu** wrote: I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );",1383160738,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tdujfoz6otc4aeopydss,task_subcomment,"**bsitu** wrote: I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );","**bsitu** wrote: I guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page echo SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,9,TRUE,"[""**bsitu** wrote:\n\nI guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page\n\necho SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );""]",NA,0,"**bsitu** wrote:\n\nI guess it's an configuration problem in ee-flow labs instance, the code below outputs 'http' in /maintenance/eval.php and 'https' in a web page\n\necho SpecialPage::getTitleFor( 'Flow', 'Test' )->getFullURL( 'foo=bar', false, PROTO_HTTPS );",OBSERVED BUG BEHAVIOR,, 13649,Flow: SSL error on email notifications,"The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/375, but people from the community are welcome to contribute here and in Gerrit.",1383032735,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-tdujfoz6otc4aeopydss,task_subcomment,"The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/375, but people from the community are welcome to contribute here and in Gerrit.",The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,['The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit.'],NA,0,The WMF core features team tracks this bug on Mingle card URL but people from the community are welcome to contribute here and in Gerrit.,ISSUE CONTENT MANAGEMENT,, 13650,Flow: SSL error on email notifications,What's an example link of what you're being given?,1382995963,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tdujfoz6otc4aeopydss,task_subcomment,What's an example link of what you're being given?,What's an example link of what you're being given?,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,8,TRUE,"[""What's an example link of what you're being given?""]",NA,0,What's an example link of what you're being given?,BUG REPRODUCTION,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.,OBSERVED BUG BEHAVIOR,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Started to happen after updating Jenkins Git plugin.,BUG REPRODUCTION,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Reverting the plugin to a earlier version did not help.,SOLUTION DISCUSSION,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,workaround it so clone the repositories via SSH[2].,WORKAROUND,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Contacted Cloudbees support[3].,WORKAROUND,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,They were able to reproduce the problem[4] and fix it.,TASK PROGRESS,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 13665,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Example[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal",1382619360,PHID-USER-fz7hkyvt4jypl76ieyol,PHID-TASK-drck3ontm2hvae6wzpnc,task_description,"Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Translate ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: https://wmf.ci.cloudbees.com/view/r-tr/job/Translate-sandbox.translatewiki.net-linux-firefox/5/console 2: https://gerrit.wikimedia.org/r/#/c/91369/2/docs/template.md 3: https://cloudbees.zendesk.com/requests/14067 4: https://issues.jenkins-ci.org/browse/JENKINS-20218 -------------------------- **Version**: unspecified **Severity**: normal","Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP./n/nExample[1]: ... ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone URL ... Started to happen after updating Jenkins Git plugin. Reverting the plugin to a earlier version did not help. WORKAROUNDS it so clone the repositories via SSH[2]. Contacted Cloudbees support[3]. They were able to reproduce the problem[4] and fix it. 1: URL 2: URL 3: URL 4: URL -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1382619967,NA,resolved,TRUE,c2,3,FALSE,FALSE,8,TRUE,"['Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP.', ""Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n..."", 'Started to happen after updating Jenkins Git plugin.', 'Reverting the plugin to a earlier version did not help.', 'WORKAROUNDS it so clone the repositories via SSH[2].', 'Contacted Cloudbees support[3].', 'They were able to reproduce the problem[4] and fix it.', '1: URL\n2: URL\n3: URL\n4: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Example[1]:\n\n...\nERROR: Error cloning remote repo 'origin'\nhudson.plugins.git.GitException: Could not clone URL\n...,OBSERVED BUG BEHAVIOR,, 13666,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Change 91593 merged by Cmcmahon: Clone Git repositories via anonymous HTTP https://gerrit.wikimedia.org/r/91593",1382628110,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-drck3ontm2hvae6wzpnc,task_subcomment,"Change 91593 merged by Cmcmahon: Clone Git repositories via anonymous HTTP https://gerrit.wikimedia.org/r/91593","Change 91593 merged by Cmcmahon: Clone Git repositories via anonymous HTTP GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,['Change 91593 merged by Cmcmahon:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL'],NA,0,Change 91593 merged by Cmcmahon:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL,TASK PROGRESS,, 13667,Cloudbees Jenkins can not clone Git repositories via Anonymous HTTP,"Change 91593 had a related patch set uploaded by Zfilipin: Clone Git repositories via anonymous HTTP https://gerrit.wikimedia.org/r/91593",1382619640,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-drck3ontm2hvae6wzpnc,task_subcomment,"Change 91593 had a related patch set uploaded by Zfilipin: Clone Git repositories via anonymous HTTP https://gerrit.wikimedia.org/r/91593","Change 91593 had a related patch set uploaded by Zfilipin: Clone Git repositories via anonymous HTTP GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,['Change 91593 had a related patch set uploaded by Zfilipin:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL'],NA,0,Change 91593 had a related patch set uploaded by Zfilipin:\nClone Git repositories via anonymous HTTP\n\nGERRIT_URL,TASK PROGRESS,, 13752,Can't login to wikisource.org,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_description,"Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Needs Triage,90,1384635692,NA,invalid,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,The following was outputted when I tried\nfamily = \,BUG REPRODUCTION,, 13752,Can't login to wikisource.org,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_description,"Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Needs Triage,90,1384635692,NA,invalid,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,\nmylang = \,NA,, 13752,Can't login to wikisource.org,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_description,"Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Needs Triage,90,1384635692,NA,invalid,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL",OBSERVED BUG BEHAVIOR,, 13752,Can't login to wikisource.org,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_description,"Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Needs Triage,90,1384635692,NA,invalid,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Can't login to wikisource.org.,OBSERVED BUG BEHAVIOR,, 13752,Can't login to wikisource.org,"Originally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572",1380947640,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_description,"Can't login to wikisource.org./n/nOriginally from: http://sourceforge.net/p/pywikipediabot/bugs/1572/ Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, http://wikisource.org/ does not redirect to http://en.wikisource.org/ and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://sourceforge.net/p/pywikipediabot/bugs/1572","Can't login to wikisource.org./n/nOriginally from: URL Reported by: Anonymous user Created on: 2013-02-09 09:45:00 Subject: Can't login to wikisource.org Original description: I would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script. The following was outputted when I tried family = 'wikisource' mylang = '' Traceback \(most recent call last\): File ""C:\Python27\pywikipedia1\redirect.py"", line 65, in <module> import wikipedia as pywikibot File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8717, in <module> getSite\(noLogin=True\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 8471, in getSite \_sites\[key\] = Site\(code=code, fam=fam, user=user\) File ""C:\Python27\pywikipedia1\pywikibot\support.py"", line 115, in wrapper return method\(\*\_\_args, \*\*\_\_kw\) File ""C:\Python27\pywikipedia1\wikipedia.py"", line 5667, in \_\_init\_\_ % \(self.\_\_code, self.\_\_family.name\)\) NoSuchSite: Language does not exist in family wikisource -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Needs Triage,90,1384635692,NA,invalid,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Can't login to wikisource.org."", ""Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script."", 'The following was outputted when I tried\nfamily = \'wikisource\'\nmylang = \'\'\n\nTraceback \\(most recent call last\\):\nFile ""C:\\Python27\\pywikipedia1\\redirect.py"", line 65, in <module>\nimport wikipedia as pywikibot\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8717, in <module>\ngetSite\\(noLogin=True\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 8471, in getSite\n\\_sites\\[key\\] = Site\\(code=code, fam=fam, user=user\\)\nFile ""C:\\Python27\\pywikipedia1\\pywikibot\\support.py"", line 115, in wrapper\nreturn method\\(\\*\\_\\_args, \\*\\*\\_\\_kw\\)\nFile ""C:\\Python27\\pywikipedia1\\wikipedia.py"", line 5667, in \\_\\_init\\_\\_\n% \\(self.\\_\\_code, self.\\_\\_family.name\\)\\)\nNoSuchSite: Language does not exist in family wikisource\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Originally from: URL\nReported by: Anonymous user\nCreated on: 2013-02-09 09:45:00\nSubject: Can't login to wikisource.org\nOriginal description:\nI would like to be able to edit Wikisource with pywikipediabot; unlike all the other wikis, URL does not redirect to URL and thus I cannot login to wikisource.org without playing with each script.",OBSERVED BUG BEHAVIOR,, 13753,Can't login to wikisource.org,closed per above,1384635692,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,closed per above,closed per above,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,11,TRUE,['closed per above'],NA,0,closed per above,ACTION ON ISSUE,, 13754,Can't login to wikisource.org,"Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",1380947670,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,"Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"['Suggested method works, please close or possibly add a note somewhere in the code?', ""\\(so people like me can see that they need to do '-'\\)""]",NA,0,"Suggested method works, please close or possibly add a note somewhere in the code?",ACTION ON ISSUE,, 13754,Can't login to wikisource.org,"Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",1380947670,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,"Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)","Suggested method works, please close or possibly add a note somewhere in the code? \(so people like me can see that they need to do '-'\)",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"['Suggested method works, please close or possibly add a note somewhere in the code?', ""\\(so people like me can see that they need to do '-'\\)""]",NA,0,\\(so people like me can see that they need to do '-'\\),MOTIVATION,, 13755,Can't login to wikisource.org,"My mistake, I didn't see the suggested method.",1380947668,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,"My mistake, I didn't see the suggested method.","My mistake, I didn't see the suggested method.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""My mistake, I didn't see the suggested method.""]",NA,0,"My mistake, I didn't see the suggested method.",SOCIAL CONVERSATION,, 13756,Can't login to wikisource.org,- **priority**: 7 --> 5,1380947666,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,- **priority**: 7 --> 5,- **priority**: 7 --> 5,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,['- **priority**: 7 --> 5'],NA,0,- **priority**: 7 --> 5,ACTION ON ISSUE,, 13757,Can't login to wikisource.org,Please try the suggested method before increading priority.,1380947665,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,Please try the suggested method before increading priority.,Please try the suggested method before increading priority.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,['Please try the suggested method before increading priority.'],NA,0,Please try the suggested method before increading priority.,CONTRIBUTION AND COMMITMENT,, 13758,Can't login to wikisource.org,- **priority**: 5 --> 7,1380947663,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,- **priority**: 5 --> 7,- **priority**: 5 --> 7,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,['- **priority**: 5 --> 7'],NA,0,- **priority**: 5 --> 7,ACTION ON ISSUE,, 13759,Can't login to wikisource.org,"Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).",1380947661,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-dhh37twcrmhqe6k4pknu,task_subcomment,"Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).","Instead of mylang='', try using mylang='-' \(and also adapting your username config as such\).",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""Instead of mylang='', try using mylang='-' \\(and also adapting your username config as such\\).""]",NA,0,"Instead of mylang='', try using mylang='-' \\(and also adapting your username config as such\\).",WORKAROUND,, 13985,Login with the required password change doesn't log me in globally,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",1380793140,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-4yoprjxsxryoacxktvyk,task_description,"Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1696629317,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"In the recent user data leaking issue, we forced users to change password on login.",SOLUTION USAGE,, 13985,Login with the required password change doesn't log me in globally,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",1380793140,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-4yoprjxsxryoacxktvyk,task_description,"Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1696629317,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.",OBSERVED BUG BEHAVIOR,, 13985,Login with the required password change doesn't log me in globally,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",1380793140,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-4yoprjxsxryoacxktvyk,task_description,"Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1696629317,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 13985,Login with the required password change doesn't log me in globally,"In the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",1380793140,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-4yoprjxsxryoacxktvyk,task_description,"Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal","Login with the required password change doesn't log me in globally./n/nIn the recent user data leaking issue, we forced users to change password on login. After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1696629317,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c2,3,FALSE,FALSE,5,TRUE,"[""Login with the required password change doesn't log me in globally."", 'In the recent user data leaking issue, we forced users to change password on login.', 'After password is changed, the user is logged locally (and also project-wise, eg, for other wikipedia sites) automatically, but not logged in on another project.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,Login with the required password change doesn't log me in globally.,OBSERVED BUG BEHAVIOR,, 13986,Login with the required password change doesn't log me in globally,"Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.",1696629317,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.","Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,527,TRUE,"[""Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.""]",NA,0,"Please reopen if this is still an issue, but I'm pretty sure it was fixed by AuthManager - other parts of the login stack, such as CentralAuth, now don't know whether there was a password change step.",TASK PROGRESS,, 13987,Login with the required password change doesn't log me in globally,@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!,1544893724,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!,SCREEN_NAME: Please see and follow URL and report back here. Thanks!,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,276,TRUE,"['SCREEN_NAME: Please see and follow URL and report back here.', 'Thanks!']",NA,0,SCREEN_NAME: Please see and follow URL and report back here.,CONTRIBUTION AND COMMITMENT,, 13987,Login with the required password change doesn't log me in globally,@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!,1544893724,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,@Piramidion: Please see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems and report back here. Thanks!,SCREEN_NAME: Please see and follow URL and report back here. Thanks!,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,276,TRUE,"['SCREEN_NAME: Please see and follow URL and report back here.', 'Thanks!']",NA,0,Thanks!,SOCIAL CONVERSATION,, 13988,Login with the required password change doesn't log me in globally,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,PHID-USER-236lfjw5qszgahq5srnq,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,276,TRUE,"['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,A user reported this recently.,SOCIAL CONVERSATION,, 13988,Login with the required password change doesn't log me in globally,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,PHID-USER-236lfjw5qszgahq5srnq,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,276,TRUE,"['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,He also says that the system randomly logs him out on Wikipedia too.,POTENTIAL NEW ISSUES AND REQUESTS,, 13988,Login with the required password change doesn't log me in globally,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,PHID-USER-236lfjw5qszgahq5srnq,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,276,TRUE,"['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",WORKAROUND,, 13988,Login with the required password change doesn't log me in globally,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,PHID-USER-236lfjw5qszgahq5srnq,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,276,TRUE,"['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords.",OBSERVED BUG BEHAVIOR,, 13988,Login with the required password change doesn't log me in globally,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",1544890597,PHID-USER-236lfjw5qszgahq5srnq,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?","A user reported this recently. Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords. It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons. He also says that the system randomly logs him out on Wikipedia too. Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,276,TRUE,"['A user reported this recently.', ""Apparently he's using a temporary password, as he doesn't know neither his current, nor his old passwords."", ""It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons."", 'He also says that the system randomly logs him out on Wikipedia too.', 'Is there a way to fix this issue as per user, so that he can keep working like usual, until this entire problem is resolved?']",NA,0,"It stays saved in his browser, so he's able to log into Wikipedia, but the problem is he cannot log into any other project, like Wikidata or Commons.",OBSERVED BUG BEHAVIOR,, 13989,Login with the required password change doesn't log me in globally,I haven't been able to get to it yet,1400026541,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,I haven't been able to get to it yet,I haven't been able to get to it yet,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,37,TRUE,"[""I haven't been able to get to it yet""]",NA,0,I haven't been able to get to it yet,CONTRIBUTION AND COMMITMENT,, 13990,Login with the required password change doesn't log me in globally,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4) QUOTE QUOTE Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,36,TRUE,"['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,"(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.",SOCIAL CONVERSATION,, 13990,Login with the required password change doesn't log me in globally,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4) QUOTE QUOTE Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,36,TRUE,"['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,timeframe?,CONTRIBUTION AND COMMITMENT,, 13990,Login with the required password change doesn't log me in globally,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)",1399878048,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"(In reply to Chris Steipp from comment #4) > Platform has let me schedule some password work this quarter, which this > falls under. So March-ish is a good target. Chris: How did reality bite, and any new approx. timeframe? :)","(In reply to Chris Steipp from comment #4) QUOTE QUOTE Chris: How did reality bite, and any new approx. timeframe? :)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,36,TRUE,"['(In reply to Chris Steipp from comment #4)\nQUOTE\nQUOTE\n\nChris: How did reality bite, and any new approx.', 'timeframe?', ':)']",NA,0,:),SOCIAL CONVERSATION,, 13991,Login with the required password change doesn't log me in globally,"Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",1389291226,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,19,TRUE,"['Platform has let me schedule some password work this quarter, which this falls under.', 'So March-ish is a good target.']",NA,0,"Platform has let me schedule some password work this quarter, which this falls under.",CONTRIBUTION AND COMMITMENT,, 13991,Login with the required password change doesn't log me in globally,"Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",1389291226,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.","Platform has let me schedule some password work this quarter, which this falls under. So March-ish is a good target.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,19,TRUE,"['Platform has let me schedule some password work this quarter, which this falls under.', 'So March-ish is a good target.']",NA,0,So March-ish is a good target.,FUTURE PLANS,, 13992,Login with the required password change doesn't log me in globally,"(In reply to comment #2 by csteipp) > I'm planning to rework the patches we put in for this particular incident, > which will do the full SUL2 handshake after the login finishes. csteipp: Any vague timeframe (if this is still the plan)?",1389267605,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"(In reply to comment #2 by csteipp) > I'm planning to rework the patches we put in for this particular incident, > which will do the full SUL2 handshake after the login finishes. csteipp: Any vague timeframe (if this is still the plan)?","(In reply to comment #2 by csteipp) QUOTE QUOTE csteipp: Any vague timeframe (if this is still the plan)?",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,19,TRUE,['(In reply to comment #2 by csteipp)\nQUOTE\nQUOTE\n\ncsteipp: Any vague timeframe (if this is still the plan)?'],NA,0,(In reply to comment #2 by csteipp)\nQUOTE\nQUOTE\n\ncsteipp: Any vague timeframe (if this is still the plan)?,CONTRIBUTION AND COMMITMENT,, 13993,Login with the required password change doesn't log me in globally,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,I saw this last night.,SOCIAL CONVERSATION,, 13993,Login with the required password change doesn't log me in globally,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,"You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects.",INVESTIGATION AND EXPLORATION,, 13993,Login with the required password change doesn't log me in globally,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",1380820150,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.","I saw this last night. You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects. I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['I saw this last night.', ""You're actually logged in as your SUL user (as you noted, but being logged into other wikipedia.org subdomains), but we don't do the redirect through loginwiki since the normal login hooks aren't called, so you won't be logged into the other projects."", ""I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.""]",NA,0,"I'm planning to rework the patches we put in for this particular incident, which will do the full SUL2 handshake after the login finishes.",CONTRIBUTION AND COMMITMENT,, 13994,Login with the required password change doesn't log me in globally,"Logins using temporary password (""Reset your password"" feature) are also affected.",1380793429,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-4yoprjxsxryoacxktvyk,task_subcomment,"Logins using temporary password (""Reset your password"" feature) are also affected.","Logins using temporary password (""Reset your password"" feature) are also affected.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"['Logins using temporary password (""Reset your password"" feature) are also affected.']",NA,0,"Logins using temporary password (""Reset your password"" feature) are also affected.",INVESTIGATION AND EXPLORATION,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,forceHTTPS session cookie placed even with HTTPS opt-out set.,OBSERVED BUG BEHAVIOR,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\",OBSERVED BUG BEHAVIOR,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,", ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI",OBSERVED BUG BEHAVIOR,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"s force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it",OBSERVED BUG BEHAVIOR,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,Why do the technical people have meddle so... and not tell us.,SOCIAL CONVERSATION,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal",OBSERVED BUG BEHAVIOR,, 13995,forceHTTPS session cookie placed even with HTTPS opt-out set,"Forced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",1380185580,PHID-USER-wrimmmr5w2zt7nk2t753,PHID-TASK-yk4yz7wimv556d7eqmvv,task_description,"forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal","forceHTTPS session cookie placed even with HTTPS opt-out set./n/nForced secure connection...again...[edit] Even though the ""always use a secure connection"" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC) Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC) I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC) I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC) -------------------------- **Version**: master **Severity**: normal",High,80,1381853735,NA,resolved,TRUE,c2,3,FALSE,FALSE,4,TRUE,"['forceHTTPS session cookie placed even with HTTPS opt-out set.', 'Forced secure connection...again...[edit]\n\nEven though the ""always use a secure connection"" box is unchecked, I\'m being redirected to https:// no matter what I do on each and every page.', 'This is becoming bothersome.', '- The Bushranger One ping only 22:43, 25 September 2013 (UTC)\n\n\nWhich browser are you using?', 'If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back.', ""--Redrose64 (talk) 23:09, 25 September 2013 (UTC)\n\n\nI'm using FF22."", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ""There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using URL as soon as I signed out and back in again, I was right back stuck on URL This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning."", ""- The Bushranger One ping only 23:25, 25 September 2013 (UTC)\n\n\nI tried deleting and had similar problems - it's also force feeding me that cookie every time I log in."", 'Why do the technical people have meddle so... and not tell us.', 'Dpmuk (talk) 06:07, 26 September 2013 (UTC)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,", 'I tried that - but there was no forceHTTPS cookie after I logged out per the directions there.', ",INVESTIGATION AND EXPLORATION,, 13996,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",1382118210,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.","**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.,BUG REPRODUCTION,, 13996,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",1382118210,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.","**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,Using Google Translate on a Wikipedia page.,SOLUTION USAGE,, 13996,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",1382118210,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.","**salisria** wrote: I have managed to reproduce it and this time noticed the trigger. Using Google Translate on a Wikipedia page. I have filed a new bug, Bug 55887.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['**salisria** wrote:\n\nI have managed to reproduce it and this time noticed the trigger.', 'Using Google Translate on a Wikipedia page.', 'I have filed a new bug, Bug 55887.']",NA,0,"I have filed a new bug, Bug 55887.",ISSUE CONTENT MANAGEMENT,, 13997,forceHTTPS session cookie placed even with HTTPS opt-out set,Confirmed fixed in a Chrome private browser session with HTTPS disabled.,1381943703,PHID-USER-766idcqt4jkngnnuhnrj,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,Confirmed fixed in a Chrome private browser session with HTTPS disabled.,Confirmed fixed in a Chrome private browser session with HTTPS disabled.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,['Confirmed fixed in a Chrome private browser session with HTTPS disabled.'],NA,0,Confirmed fixed in a Chrome private browser session with HTTPS disabled.,TASK PROGRESS,, 13998,forceHTTPS session cookie placed even with HTTPS opt-out set,"If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.",1381853735,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.","If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,6,TRUE,"[""If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.""]",NA,0,"If you can reproduce this now that you've logged out and logged back in, please file a new bug with specific instructions on reproducing.",BUG REPRODUCTION,, 13999,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"**salisria** wrote:\n\nOkay, just tried one more thing.",INVESTIGATION AND EXPLORATION,, 13999,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"Clearing the cookies, logging out, and logging back in.",INVESTIGATION AND EXPLORATION,, 13999,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,That worked.,SOCIAL CONVERSATION,, 13999,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",1381705099,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.","**salisria** wrote: Okay, just tried one more thing. Clearing the cookies, logging out, and logging back in. That worked. But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nOkay, just tried one more thing.', 'Clearing the cookies, logging out, and logging back in.', 'That worked.', 'But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.']",NA,0,"But still, I should not have ever gotten into the state I was in of it forcing me into HTTPS, so something is still wonky, even if intermittently so.",POTENTIAL NEW ISSUES AND REQUESTS,, 14000,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,**salisria** wrote:\n\nJust realized something.,SOCIAL CONVERSATION,, 14000,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"One of the cookies was ""wikipedia.org"".",INVESTIGATION AND EXPLORATION,, 14000,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.",INVESTIGATION AND EXPLORATION,, 14000,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",1381703793,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?","**salisria** wrote: Just realized something. One of the cookies was ""wikipedia.org"". If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc. Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**salisria** wrote:\n\nJust realized something.', 'One of the cookies was ""wikipedia.org"".', 'If I remember correctly, then before there were separate cookies for en.wikipedia.org, fr.wikipedia.org, etc.', 'Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?']",NA,0,"Did someone do an optimization to use only one cookie per domain and then forget to give us the ability to opt out since there are no preferences users can set on ""wikipedia.org"", just on the individual sites?",INVESTIGATION AND EXPLORATION,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.",OBSERVED BUG BEHAVIOR,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,Reload the page to apply your user settings.,WORKAROUND,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.",INVESTIGATION AND EXPLORATION,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,I am using Firefox 24.0.,TESTING,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug.",ACTION ON ISSUE,, 14001,forceHTTPS session cookie placed even with HTTPS opt-out set,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",1381702355,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.","**salisria** wrote: I'm getting forced into using HTTPS again today, so I'm reopening this bug. Not only that, but clearing the cookies doesn't help. If do that, then I get the popup message: Central login You are centrally logged in as XXXXXXX. Reload the page to apply your user settings. And 15 different new HTTPS cookies added: commons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary. I am using Firefox 24.0.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"[""**salisria** wrote:\n\nI'm getting forced into using HTTPS again today, so I'm reopening this bug."", ""Not only that, but clearing the cookies doesn't help."", 'If do that, then I get the popup message:\nCentral login\nYou are centrally logged in as XXXXXXX.', 'Reload the page to apply your user settings.', 'And 15 different new HTTPS cookies added:\ncommons, incubator, login, mediawiki, meta, species, wikibooks, wikidata, wikinews, wikipedia, wikiquote, wikisource, wikiversity, wikivoyage, and wiktionary.', 'I am using Firefox 24.0.']",NA,0,"Not only that, but clearing the cookies doesn't help.",INVESTIGATION AND EXPLORATION,, 14002,forceHTTPS session cookie placed even with HTTPS opt-out set,"Thanks for checking, Brad.",1381426328,PHID-USER-766idcqt4jkngnnuhnrj,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Thanks for checking, Brad.","Thanks for checking, Brad.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Thanks for checking, Brad.']",NA,0,"Thanks for checking, Brad.",SOCIAL CONVERSATION,, 14003,forceHTTPS session cookie placed even with HTTPS opt-out set,"I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.",1381422212,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.","I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,6,TRUE,"[""I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.""]",NA,0,"I don't know why it's not on that release notes page, but I just checked on tin and it is included in the version of CentralAuth in /a/common/php-1.22wmf20/extensions/CentralAuth.",INVESTIGATION AND EXPLORATION,, 14004,forceHTTPS session cookie placed even with HTTPS opt-out set,Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20,1381391926,PHID-USER-766idcqt4jkngnnuhnrj,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20,Is this in fact in wmf20? I don't see it in the release notes in URL,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Is this in fact in wmf20?', ""I don't see it in the release notes in URL""]",NA,0,Is this in fact in wmf20?,INVESTIGATION AND EXPLORATION,, 14004,forceHTTPS session cookie placed even with HTTPS opt-out set,Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20,1381391926,PHID-USER-766idcqt4jkngnnuhnrj,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,Is this in fact in wmf20? I don't see it in the release notes in https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf20,Is this in fact in wmf20? I don't see it in the release notes in URL,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Is this in fact in wmf20?', ""I don't see it in the release notes in URL""]",NA,0,I don't see it in the release notes in URL,INVESTIGATION AND EXPLORATION,, 14005,forceHTTPS session cookie placed even with HTTPS opt-out set,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,1381072702,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"['%%%*** Bug 55368 has been marked as a duplicate of this bug.', '***%%%']",NA,0,%%%*** Bug 55368 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 14005,forceHTTPS session cookie placed even with HTTPS opt-out set,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,1381072702,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,%%%*** Bug 55368 has been marked as a duplicate of this bug. ***%%%,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"['%%%*** Bug 55368 has been marked as a duplicate of this bug.', '***%%%']",NA,0,***%%%,NA,, 14006,forceHTTPS session cookie placed even with HTTPS opt-out set,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"Marking this fixed, since the patch is merged.",ACTION ON ISSUE,, 14006,forceHTTPS session cookie placed even with HTTPS opt-out set,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.",SOLUTION USAGE,, 14006,forceHTTPS session cookie placed even with HTTPS opt-out set,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,See URL for the schedule.,SOCIAL CONVERSATION,, 14006,forceHTTPS session cookie placed even with HTTPS opt-out set,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",1380298508,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).","Marking this fixed, since the patch is merged. It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20. See URL for the schedule. Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Marking this fixed, since the patch is merged.', 'It looks like this just missed being included in 1.22wmf19, so it should go out to WMF wikis with 1.22wmf20.', 'See URL for the schedule.', 'Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).']",NA,0,"Unless, of course, Chris or someone wants to backport it (which would probably happen then on Monday).",CONTRIBUTION AND COMMITMENT,, 14007,forceHTTPS session cookie placed even with HTTPS opt-out set,"Change 86101 merged by jenkins-bot: Explicitly clear forceHTTPS cookie when insecure https://gerrit.wikimedia.org/r/86101",1380233997,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Change 86101 merged by jenkins-bot: Explicitly clear forceHTTPS cookie when insecure https://gerrit.wikimedia.org/r/86101","Change 86101 merged by jenkins-bot: Explicitly clear forceHTTPS cookie when insecure GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,4,TRUE,['Change 86101 merged by jenkins-bot:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL'],NA,0,Change 86101 merged by jenkins-bot:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL,TASK PROGRESS,, 14008,forceHTTPS session cookie placed even with HTTPS opt-out set,"Change 86101 had a related patch set uploaded by Anomie: Explicitly clear forceHTTPS cookie when insecure https://gerrit.wikimedia.org/r/86101",1380205862,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"Change 86101 had a related patch set uploaded by Anomie: Explicitly clear forceHTTPS cookie when insecure https://gerrit.wikimedia.org/r/86101","Change 86101 had a related patch set uploaded by Anomie: Explicitly clear forceHTTPS cookie when insecure GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,4,TRUE,['Change 86101 had a related patch set uploaded by Anomie:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL'],NA,0,Change 86101 had a related patch set uploaded by Anomie:\nExplicitly clear forceHTTPS cookie when insecure\n\nGERRIT_URL,TASK PROGRESS,, 14009,forceHTTPS session cookie placed even with HTTPS opt-out set,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not. For the records: URL URL",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,Or not.,SOCIAL CONVERSATION,, 14009,forceHTTPS session cookie placed even with HTTPS opt-out set,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not. For the records: URL URL",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,For the records: URL\nURL,SOCIAL CONVERSATION,, 14009,forceHTTPS session cookie placed even with HTTPS opt-out set,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue",1380197962,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-yk4yz7wimv556d7eqmvv,task_subcomment,"I wonder if this is covered by anomie's https://gerrit.wikimedia.org/r/#/c/85776/ . Or not. For the records: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#Forced_secure_connection...again... https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574592983#http_login_issue","I wonder if this is covered by anomie's URL . Or not. For the records: URL URL",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"[""I wonder if this is covered by anomie's URL ."", 'Or not.', 'For the records: URL\nURL']",NA,0,I wonder if this is covered by anomie's URL .,INVESTIGATION AND EXPLORATION,, 14069,Create global account on login/rename,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-h4tu4j445kger6aygazx,task_description,"Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",High,80,1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,declined,TRUE,c2,3,FALSE,FALSE,1,TRUE,"['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,Create global account on login/rename.,EXPECTED BEHAVIOR,, 14069,Create global account on login/rename,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-h4tu4j445kger6aygazx,task_description,"Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",High,80,1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,declined,TRUE,c2,3,FALSE,FALSE,1,TRUE,"['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.",EXPECTED BEHAVIOR,, 14069,Create global account on login/rename,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-h4tu4j445kger6aygazx,task_description,"Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",High,80,1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,declined,TRUE,c2,3,FALSE,FALSE,1,TRUE,"['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.",POTENTIAL NEW ISSUES AND REQUESTS,, 14069,Create global account on login/rename,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-h4tu4j445kger6aygazx,task_description,"Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",High,80,1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,declined,TRUE,c2,3,FALSE,FALSE,1,TRUE,"['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,Should be part of a automigration (wgCentralAuthAutoMigrate).,SOLUTION DISCUSSION,, 14069,Create global account on login/rename,"When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862",1378630560,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-h4tu4j445kger6aygazx,task_description,"Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=14862","Create global account on login/rename./n/nWhen a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically. Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this. Should be part of a automigration (wgCentralAuthAutoMigrate). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",High,80,1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,declined,TRUE,c2,3,FALSE,FALSE,1,TRUE,"['Create global account on login/rename.', 'When a user gets renamed locally to a new name, under which no global account exists and no conflicts accounts exists, the global account should be created automatically.', 'Maybe this can also be checked on user login, than other (or the previous renamed) user accounts without a conflict can also benefit from this.', 'Should be part of a automigration (wgCentralAuthAutoMigrate).', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 14070,Create global account on login/rename,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,89,TRUE,"['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?",ACTION ON ISSUE,, 14070,Create global account on login/rename,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,89,TRUE,"['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,Did you run into a bug with drag and drop in phabricator workboards?,INVESTIGATION AND EXPLORATION,, 14070,Create global account on login/rename,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,89,TRUE,"['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,"If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.",POTENTIAL NEW ISSUES AND REQUESTS,, 14070,Create global account on login/rename,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",1431506795,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(","MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952? Did you run into a bug with drag and drop in phabricator workboards? If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching. :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,89,TRUE,"['MarcoAurelio, why are you mass-changing priorities to ""High"", as in T55905#1261952?', 'Did you run into a bug with drag and drop in phabricator workboards?', 'If so, please report it; I thought it was filed already, but Phabricator search is too poor for me to find it even after 30 min of searching.', ':(']",NA,0,:(,SOCIAL CONVERSATION,, 14071,Create global account on login/rename,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,87,TRUE,"['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.",TASK PROGRESS,, 14071,Create global account on login/rename,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,87,TRUE,"['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,Feel free to reopen if you feel the problem still exist.,ACTION ON ISSUE,, 14071,Create global account on login/rename,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",1430851335,PHID-USER-xvs3y6hf6yrfn6sxrk5d,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.","I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user. Feel free to reopen if you feel the problem still exist. Thanks.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,87,TRUE,"['I think this is not an issue anymore with global renames, as the global account is created when globally renaming an user.', 'Feel free to reopen if you feel the problem still exist.', 'Thanks.']",NA,0,Thanks.,SOCIAL CONVERSATION,, 14072,Create global account on login/rename,"Change 102635 abandoned by Legoktm: Autocreate global account after rename Reason: Not worth it at this point https://gerrit.wikimedia.org/r/102635",1412924758,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"Change 102635 abandoned by Legoktm: Autocreate global account after rename Reason: Not worth it at this point https://gerrit.wikimedia.org/r/102635","Change 102635 abandoned by Legoktm: Autocreate global account after rename Reason: Not worth it at this point GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,58,TRUE,['Change 102635 abandoned by Legoktm:\nAutocreate global account after rename\n\nReason:\nNot worth it at this point\n\nGERRIT_URL'],NA,0,Change 102635 abandoned by Legoktm:\nAutocreate global account after rename\n\nReason:\nNot worth it at this point\n\nGERRIT_URL,TASK PROGRESS,, 14073,Create global account on login/rename,"Change 102635 had a related patch set uploaded by Legoktm: Autocreate global account after rename https://gerrit.wikimedia.org/r/102635",1387441864,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"Change 102635 had a related patch set uploaded by Legoktm: Autocreate global account after rename https://gerrit.wikimedia.org/r/102635","Change 102635 had a related patch set uploaded by Legoktm: Autocreate global account after rename GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,16,TRUE,['Change 102635 had a related patch set uploaded by Legoktm:\nAutocreate global account after rename\n\nGERRIT_URL'],NA,0,Change 102635 had a related patch set uploaded by Legoktm:\nAutocreate global account after rename\n\nGERRIT_URL,TASK PROGRESS,, 14074,Create global account on login/rename,"(In reply to comment #0) > Maybe this can also be checked on user login, than other (or the previous > renamed) user accounts without a conflict can also benefit from this. Should > be > part of a automigration (wgCentralAuthAutoMigrate). According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.",1387441778,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-h4tu4j445kger6aygazx,task_subcomment,"(In reply to comment #0) > Maybe this can also be checked on user login, than other (or the previous > renamed) user accounts without a conflict can also benefit from this. Should > be > part of a automigration (wgCentralAuthAutoMigrate). According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.","(In reply to comment #0) QUOTE QUOTE QUOTE QUOTE According to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,16,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAccording to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAccording to the documentation of $wgCentralAuthAutoMigrate, this should already happen if it is enabled.",INVESTIGATION AND EXPLORATION,, 14116,No forcehttps cookies for sister projects on AutoLogin,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",1376968620,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_description,"No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1380298784,NA,resolved,TRUE,c2,2,TRUE,FALSE,-2,TRUE,"['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,No forcehttps cookies for sister projects on AutoLogin.,OBSERVED BUG BEHAVIOR,, 14116,No forcehttps cookies for sister projects on AutoLogin,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",1376968620,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_description,"No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1380298784,NA,resolved,TRUE,c2,2,TRUE,FALSE,-2,TRUE,"['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.",SOLUTION DISCUSSION,, 14116,No forcehttps cookies for sister projects on AutoLogin,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",1376968620,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_description,"No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1380298784,NA,resolved,TRUE,c2,2,TRUE,FALSE,-2,TRUE,"['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 14116,No forcehttps cookies for sister projects on AutoLogin,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",1376968620,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_description,"No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal","No forcehttps cookies for sister projects on AutoLogin./n/nWhen logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in. Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie. -------------------------- **Version**: unspecified **Severity**: normal",High,80,1380298784,NA,resolved,TRUE,c2,2,TRUE,FALSE,-2,TRUE,"['No forcehttps cookies for sister projects on AutoLogin.', ""When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in."", 'Need to add the forceHTTPS cookie, probably in the same place where we set the token cookie.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"When logging in, and wgSecureLogin is used, the forceHTTPS cookie (to have mediawiki redirect to https from an http call) isn't set for all SUL domains, only the project where the user is logging in.",INVESTIGATION AND EXPLORATION,, 14117,No forcehttps cookies for sister projects on AutoLogin,"Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",1380298784,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"[""Since this seems to be fixed, and the dependent bugs too, let's close this now."", ""Feel free to reopen if I'm mistaken.""]",NA,0,"Since this seems to be fixed, and the dependent bugs too, let's close this now.",ACTION ON ISSUE,, 14117,No forcehttps cookies for sister projects on AutoLogin,"Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",1380298784,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.","Since this seems to be fixed, and the dependent bugs too, let's close this now. Feel free to reopen if I'm mistaken.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"[""Since this seems to be fixed, and the dependent bugs too, let's close this now."", ""Feel free to reopen if I'm mistaken.""]",NA,0,Feel free to reopen if I'm mistaken.,ACTION ON ISSUE,, 14118,No forcehttps cookies for sister projects on AutoLogin,I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.,1377793627,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.,I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,0,TRUE,['I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.'],NA,0,I also opened the bug 53538 which can be considered as an other specific issue due to the fact wgCookiePrefix is language-specific.,ISSUE CONTENT MANAGEMENT,, 14119,No forcehttps cookies for sister projects on AutoLogin,"Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",1377791228,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,0,TRUE,"['Second half of the patch was added as a bug by Seb35.', 'Probably good to keep this as a tracking bug, and that one for the specific issue.']",NA,0,Second half of the patch was added as a bug by Seb35.,ACTION ON ISSUE,, 14119,No forcehttps cookies for sister projects on AutoLogin,"Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",1377791228,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.","Second half of the patch was added as a bug by Seb35. Probably good to keep this as a tracking bug, and that one for the specific issue.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,0,TRUE,"['Second half of the patch was added as a bug by Seb35.', 'Probably good to keep this as a tracking bug, and that one for the specific issue.']",NA,0,"Probably good to keep this as a tracking bug, and that one for the specific issue.",ISSUE CONTENT MANAGEMENT,, 14120,No forcehttps cookies for sister projects on AutoLogin,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,0,TRUE,"['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,That patch only sets the cookies.,SOLUTION DISCUSSION,, 14120,No forcehttps cookies for sister projects on AutoLogin,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,0,TRUE,"['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,"Still need to clean up from them on logout, which requires touching every wiki.",SOLUTION DISCUSSION,, 14120,No forcehttps cookies for sister projects on AutoLogin,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",1377733592,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.","That patch only sets the cookies. Still need to clean up from them on logout, which requires touching every wiki. That will be a more complex patch.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,0,TRUE,"['That patch only sets the cookies.', 'Still need to clean up from them on logout, which requires touching every wiki.', 'That will be a more complex patch.']",NA,0,That will be a more complex patch.,SOLUTION DISCUSSION,, 14121,No forcehttps cookies for sister projects on AutoLogin,"Change 81591 merged by jenkins-bot: Set forceHTTPS cookies for Autologin wikis https://gerrit.wikimedia.org/r/81591",1377729697,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Change 81591 merged by jenkins-bot: Set forceHTTPS cookies for Autologin wikis https://gerrit.wikimedia.org/r/81591","Change 81591 merged by jenkins-bot: Set forceHTTPS cookies for Autologin wikis GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,0,TRUE,['Change 81591 merged by jenkins-bot:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL'],NA,0,Change 81591 merged by jenkins-bot:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL,TASK PROGRESS,, 14122,No forcehttps cookies for sister projects on AutoLogin,"Change 81591 had a related patch set uploaded by CSteipp: Set forceHTTPS cookies for Autologin wikis https://gerrit.wikimedia.org/r/81591",1377729473,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mrggh326wjh236my5dup,task_subcomment,"Change 81591 had a related patch set uploaded by CSteipp: Set forceHTTPS cookies for Autologin wikis https://gerrit.wikimedia.org/r/81591","Change 81591 had a related patch set uploaded by CSteipp: Set forceHTTPS cookies for Autologin wikis GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,0,TRUE,['Change 81591 had a related patch set uploaded by CSteipp:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL'],NA,0,Change 81591 had a related patch set uploaded by CSteipp:\nSet forceHTTPS cookies for Autologin wikis\n\nGERRIT_URL,TASK PROGRESS,, 14191,login broken on beta labs,"As of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major",1374696600,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-wsyuomejiy425vjowzno,task_description,"login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" URL -------------------------- **Version**: unspecified **Severity**: major",High,80,1374759362,NA,resolved,TRUE,c2,1,FALSE,FALSE,-5,TRUE,"['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,login broken on beta labs.,OBSERVED BUG BEHAVIOR,, 14191,login broken on beta labs,"As of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major",1374696600,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-wsyuomejiy425vjowzno,task_description,"login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" URL -------------------------- **Version**: unspecified **Severity**: major",High,80,1374759362,NA,resolved,TRUE,c2,1,FALSE,FALSE,-5,TRUE,"['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.",OBSERVED BUG BEHAVIOR,, 14191,login broken on beta labs,"As of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major",1374696600,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-wsyuomejiy425vjowzno,task_description,"login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page -------------------------- **Version**: unspecified **Severity**: major","login broken on beta labs./n/nAs of 24 July, attempts to login all result in an error ""Login error There was an unexpected error logging in. Please try again..."" URL -------------------------- **Version**: unspecified **Severity**: major",High,80,1374759362,NA,resolved,TRUE,c2,1,FALSE,FALSE,-5,TRUE,"['login broken on beta labs.', 'As of 24 July, attempts to login all result in an error ""Login error\nThere was an unexpected error logging in.', 'Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"Please try again...""\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major",OBSERVED BUG BEHAVIOR,, 14192,login broken on beta labs,"Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/ I managed to log in beta :]",1374759362,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/ I managed to log in beta :]","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with URL I managed to log in beta :]",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['Congratulations Max Semenik, cookie being stripped was the issue.', 'Fixed by Mark Bergsma with URL\n\nI managed to log in beta :]']",NA,0,"Congratulations Max Semenik, cookie being stripped was the issue.",INVESTIGATION AND EXPLORATION,, 14192,login broken on beta labs,"Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/ I managed to log in beta :]",1374759362,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with https://gerrit.wikimedia.org/r/#/c/75842/ I managed to log in beta :]","Congratulations Max Semenik, cookie being stripped was the issue. Fixed by Mark Bergsma with URL I managed to log in beta :]",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['Congratulations Max Semenik, cookie being stripped was the issue.', 'Fixed by Mark Bergsma with URL\n\nI managed to log in beta :]']",NA,0,Fixed by Mark Bergsma with URL\n\nI managed to log in beta :],TASK PROGRESS,, 14193,login broken on beta labs,"Confirmed, $_COOKIE is empty.",1374704837,PHID-USER-aasrweh54ew7py3agvg2,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Confirmed, $_COOKIE is empty.","Confirmed, $_COOKIE is empty.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,"['Confirmed, $_COOKIE is empty.']",NA,0,"Confirmed, $_COOKIE is empty.",INVESTIGATION AND EXPLORATION,, 14194,login broken on beta labs,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,1374702424,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['You probably want a RT to ping mark.', 'He did some cookies related work on varnish during the afternoon.']",NA,0,You probably want a RT to ping mark.,CONTRIBUTION AND COMMITMENT,, 14194,login broken on beta labs,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,1374702424,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,You probably want a RT to ping mark. He did some cookies related work on varnish during the afternoon.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['You probably want a RT to ping mark.', 'He did some cookies related work on varnish during the afternoon.']",NA,0,He did some cookies related work on varnish during the afternoon.,OBSERVED BUG BEHAVIOR,, 14195,login broken on beta labs,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,PHID-USER-aasrweh54ew7py3agvg2,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4) QUOTE After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,"['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,"(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.",INVESTIGATION AND EXPLORATION,, 14195,login broken on beta labs,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,PHID-USER-aasrweh54ew7py3agvg2,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4) QUOTE After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,"['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,"Maybe, Varnish not letting cookies through?",INVESTIGATION AND EXPLORATION,, 14195,login broken on beta labs,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",1374701338,PHID-USER-aasrweh54ew7py3agvg2,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"(In reply to comment #4) > possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ? After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.","(In reply to comment #4) QUOTE After a quick test revert, turns out my CA changes are not the culprit. Maybe, Varnish not letting cookies through? CC Mark.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,"['(In reply to comment #4)\nQUOTE\n\nAfter a quick test revert, turns out my CA changes are not the culprit.', 'Maybe, Varnish not letting cookies through?', 'CC Mark.']",NA,0,CC Mark.,SOCIAL CONVERSATION,, 14196,login broken on beta labs,possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?,1374699529,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,possibly caused by https://gerrit.wikimedia.org/r/#/c/75772/ ?,possibly caused by URL ?,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,['possibly caused by URL ?'],NA,0,possibly caused by URL ?,INVESTIGATION AND EXPLORATION,, 14197,login broken on beta labs,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",1374698702,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki QUOTE array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,I have restarted both memcached daemon on apache32 and apache33.,INVESTIGATION AND EXPLORATION,, 14197,login broken on beta labs,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",1374698702,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki QUOTE array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\,INVESTIGATION AND EXPLORATION,, 14197,login broken on beta labs,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",1374698702,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki QUOTE array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,] = $wgObjectCaches[\,NA,, 14197,login broken on beta labs,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",1374698702,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki QUOTE array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,"];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.",INVESTIGATION AND EXPLORATION,, 14197,login broken on beta labs,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",1374698702,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki > var_dump( $wgObjectCaches['sessions'] ); array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.","I have restarted both memcached daemon on apache32 and apache33. Did not solve the issue :-] Sessions should be in memcached: $wgObjectCaches['sessions'] = $wgObjectCaches['memcached-pecl']; hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki QUOTE array(1) { [""class""]=> string(22) ""MemcachedPeclBagOStuff"" } Not sure what is happening. Need to rush out to bed right now.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['I have restarted both memcached daemon on apache32 and apache33.', 'Did not solve the issue :-]\n\nSessions should be in memcached:\n\n$wgObjectCaches[\'sessions\'] = $wgObjectCaches[\'memcached-pecl\'];\n\n\nhashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki\nQUOTE\narray(1) {\n [""class""]=>\n string(22) ""MemcachedPeclBagOStuff""\n}\n\n\n\nNot sure what is happening.', 'Need to rush out to bed right now.']",NA,0,Need to rush out to bed right now.,SOCIAL CONVERSATION,X, 14198,login broken on beta labs,"Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki > get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0 Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error > get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699 Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; > The memcached error is weird.",1374698291,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki > get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0 Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error > get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699 Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; > The memcached error is weird.","Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki QUOTE Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error QUOTE Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; QUOTE The memcached error is weird.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.', 'enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird.']",NA,0,"Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.",INVESTIGATION AND EXPLORATION,, 14198,login broken on beta labs,"Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki > get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0 Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error > get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699 Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; > The memcached error is weird.",1374698291,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki > get enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0 Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error > get enwiki:session:556d9a1698a968752c7f7c5fb5cdd699 Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; > The memcached error is weird.","Maybe the session are wrong in memcached , When login in: tail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached enwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND enwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0) enwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser] enwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded. enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) enwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND enwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699) hashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki QUOTE Getting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[] MemCached error QUOTE Getting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[] wsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX""; QUOTE The memcached error is weird.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,"['Maybe the session are wrong in memcached ,\n\nWhen login in:\n\ntail -f /data/project/logs/web.log|fgrep enwiki|fgrep -i memcached\n\n\nenwiki-36e3721b: 0.6819 9.8M [memcached] get(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-36e3721b: 0.6823 9.8M [memcached] result: NOT FOUND\nenwiki-36e3721b: 0.8519 18.2M [memcached] set(enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0)\nenwiki-f1d77f0c: 0.2077 6.8M CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]\nenwiki-f1d77f0c: 0.2294 9.8M MemcachedPeclBagOStuff::__construct: persistent Memcached object already loaded.', 'enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird.']",NA,0,"enwiki-f1d77f0c: 0.2295 9.8M [memcached] get(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\nenwiki-f1d77f0c: 0.2298 9.8M [memcached] result: NOT FOUND\nenwiki-f1d77f0c: 0.3549 18.2M [memcached] set(enwiki:session:556d9a1698a968752c7f7c5fb5cdd699)\n\n\nhashar@deployment-bastion:~$ mwscript mcc.php --wiki=enwiki\nQUOTE\nGetting enwiki:session:5dddf3cc93c79d70ea83c31b98a7c4d0[]\nMemCached error\nQUOTE\nGetting enwiki:session:556d9a1698a968752c7f7c5fb5cdd699[]\nwsLoginToken|s:32:""c722cabf4aefd1XXXXXXXXX"";\nQUOTE\n\n\nThe memcached error is weird.",INVESTIGATION AND EXPLORATION,, 14199,login broken on beta labs,"Adding last two authors in https://git.wikimedia.org/log/mediawiki%2Fextensions%2FCentralAuth/HEAD Aaron/Ori: Think either of your changes caused this on beta?",1374696892,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-wsyuomejiy425vjowzno,task_subcomment,"Adding last two authors in https://git.wikimedia.org/log/mediawiki%2Fextensions%2FCentralAuth/HEAD Aaron/Ori: Think either of your changes caused this on beta?","Adding last two authors in URL Aaron/Ori: Think either of your changes caused this on beta?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-5,TRUE,['Adding last two authors in URL\n\nAaron/Ori: Think either of your changes caused this on beta?'],NA,0,Adding last two authors in URL\n\nAaron/Ori: Think either of your changes caused this on beta?,INVESTIGATION AND EXPLORATION,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.,OBSERVED BUG BEHAVIOR,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,Log in on any wiki on orain.org (e.g.,INVESTIGATION AND EXPLORATION,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,meta.orain.org).,NA,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,2,NA,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,Go to any page on a non-orain.org wiki (e.g.,INVESTIGATION AND EXPLORATION,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,wikiconstituciocatalana.cat).,NA,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,"I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.",INVESTIGATION AND EXPLORATION,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201},OBSERVED BUG BEHAVIOR,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,Sessions don't work on non-loginwiki domains.,OBSERVED BUG BEHAVIOR,, 14273,Sessions don't work on non-loginwiki domains,"**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",1382392320,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_description,"Sessions don't work on non-loginwiki domains./n/n**Author:** `kudu` **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: https://github.com/Orain/ansible-playbook/issues/61 Here is our configuration (WIP): https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/files/LocalSettings.php.j2 We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}","Sessions don't work on non-loginwiki domains./n/n**Author:** CODE **Description:** Log showing incorrect behavior for a non-*.orain.org wiki Demo: 1. Log in on any wiki on orain.org (e.g. meta.orain.org). 2. Go to any page on a non-orain.org wiki (e.g. wikiconstituciocatalana.cat). I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki. Here is the original GitHub issue: URL Here is our configuration (WIP): URL We're running CentralAuth 1.22wmf22 (3756064). -------------------------- **Version**: master **Severity**: major **Attached**: {F12201}",Medium,50,1382563800,NA,invalid,TRUE,c2,3,FALSE,FALSE,7,TRUE,"[""Sessions don't work on non-loginwiki domains."", '**Author:** CODE\n\n**Description:**\nLog showing incorrect behavior for a non-*.orain.org wiki\n\nDemo:\n1.', 'Log in on any wiki on orain.org (e.g.', 'meta.orain.org).', '2.', 'Go to any page on a non-orain.org wiki (e.g.', 'wikiconstituciocatalana.cat).', 'I attached two logs, one showing normal behavior for an *.orain.org wiki and another showing incorrect behavior for a non-orain.org wiki.', ""Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064)."", '--------------------------\n**Version**: master\n**Severity**: major\n\n**Attached**: {F12201}']",TRUE,0,Here is the original GitHub issue: URL\nHere is our configuration (WIP): URL\nWe're running CentralAuth 1.22wmf22 (3756064).,INVESTIGATION AND EXPLORATION,, 14274,Sessions don't work on non-loginwiki domains,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,PHID-USER-u7w6n5ecde66oujx33pe,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems URL (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,"['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.),SOLUTION DISCUSSION,, 14274,Sessions don't work on non-loginwiki domains,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,PHID-USER-u7w6n5ecde66oujx33pe,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems URL (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,"['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.,SOLUTION USAGE,, 14274,Sessions don't work on non-loginwiki domains,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",1382563800,PHID-USER-u7w6n5ecde66oujx33pe,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems https://github.com/Orain/ansible-playbook/commit/9e6336b059f42560e28104b6e04108007a3f86a5 (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.","So after a fair amount of detective work.. A CA token needs to be set for each domain on login (as with the wikimedia sites.) Hence this fixed our problems URL (later altered to be a more dynamic fix for the future) Previous to this a login on espiral would create a CA token for the orain.org domain. espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,8,TRUE,"['So after a fair amount of detective work..\nA CA token needs to be set for each domain on login (as with the wikimedia sites.)', 'Hence this fixed our problems URL\n(later altered to be a more dynamic fix for the future)\n\nPrevious to this a login on espiral would create a CA token for the orain.org domain.', 'espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.']",NA,0,"espiral could not use this so it would then attempt to get a new CA token and session for espiral which it would do again, but again the CA token would remain under the orain.org domain not espiral.",INVESTIGATION AND EXPLORATION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,URL is also hosted in Orain.,INVESTIGATION AND EXPLORATION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.",BUG REPRODUCTION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"My session does stick, even after reboots or changing from a laptop to another.",SOLUTION USAGE,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,But then I have the same problems than the rest when logging to URL - which is double weird.,BUG REPRODUCTION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.",INVESTIGATION AND EXPLORATION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,"However, other Spiral users registered before the move are also finding login problems...",BUG REPRODUCTION,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,The session won't stick.,OBSERVED BUG BEHAVIOR,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,What is weird is that I'm visiting and editing espiral.org as an identified user regularly.,SOLUTION USAGE,, 14275,Sessions don't work on non-loginwiki domains,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",1382461178,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"http://espiral.org is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to http://wikiconstituciocatalana.cat - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...","URL is also hosted in Orain. I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again. The session won't stick. What is weird is that I'm visiting and editing espiral.org as an identified user regularly. My session does stick, even after reboots or changing from a laptop to another. But then I have the same problems than the rest when logging to URL - which is double weird. fwiw I'm admin in both wikis. One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki. However, other Spiral users registered before the move are also finding login problems...",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,"['URL is also hosted in Orain.', 'I have asked several users to login, and the feedback is the same: they can login (even after resetting password etc) but they end up being pushed back as anonymous users again.', ""The session won't stick."", ""What is weird is that I'm visiting and editing espiral.org as an identified user regularly."", 'My session does stick, even after reboots or changing from a laptop to another.', 'But then I have the same problems than the rest when logging to URL - which is double weird.', ""fwiw I'm admin in both wikis."", 'One difference is that I was already a user at espiral.org before it got imported to Orain, while Wikiconstituci<63><69> was created from scratch as an Orain wiki.', 'However, other Spiral users registered before the move are also finding login problems...']",NA,0,fwiw I'm admin in both wikis.,SOCIAL CONVERSATION,, 14276,Sessions don't work on non-loginwiki domains,"**kudu** wrote: Log showing expected behavior on an *.orain.org wiki **Attached**: {F12203}",1382392452,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-dgjqstpb5ozhxe7ypkp7,task_subcomment,"**kudu** wrote: Log showing expected behavior on an *.orain.org wiki **Attached**: {F12203}","**kudu** wrote: Log showing expected behavior on an *.orain.org wiki **Attached**: {F12203}",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,7,TRUE,['**kudu** wrote:\n\nLog showing expected behavior on an *.orain.org wiki\n\n**Attached**: {F12203}'],NA,0,**kudu** wrote:\n\nLog showing expected behavior on an *.orain.org wiki\n\n**Attached**: {F12203},BUG REPRODUCTION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,ULS loads many webfonts needlessly on page load.,OBSERVED BUG BEHAVIOR,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.",OBSERVED BUG BEHAVIOR,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Those are language versions of Wikipedia I hardly ever visit.,MOTIVATION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Therefore the webfonts are not used anywhere else and downloading them is quite pointless.,MOTIVATION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Therefore I strongly suggest to *not* download webfonts only for the languages list.,SOLUTION DISCUSSION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,This is pointless and only adds a huge overhead for no gain at all.,SOLUTION DISCUSSION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\",SOLUTION DISCUSSION,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example).,OBSERVED BUG BEHAVIOR,, 14665,ULS loads many webfonts needlessly on page load,"I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836",1373406780,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_description,"ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=50836","ULS loads many webfonts needlessly on page load./n/nI'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example). I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left. Those are language versions of Wikipedia I hardly ever visit. Therefore the webfonts are not used anywhere else and downloading them is quite pointless. Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now. Therefore I strongly suggest to *not* download webfonts only for the languages list. This is pointless and only adds a huge overhead for no gain at all. Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn't influence the behavior described above but loads webfonts nonetheless). The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1379659385,NA,resolved,TRUE,c2,1,FALSE,FALSE,-8,TRUE,"['ULS loads many webfonts needlessly on page load.', ""I'm noticing considerably delayed page load since ULS became active on some pages ([[en:Special:RecentChanges]] is an impressive example)."", 'I realized this is because of ULS loading a whole lot of webfonts only to use them on foreign language names in the ""Languages"" list on the left.', 'Those are language versions of Wikipedia I hardly ever visit.', 'Therefore the webfonts are not used anywhere else and downloading them is quite pointless.', ""Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now."", 'Therefore I strongly suggest to *not* download webfonts only for the languages list.', 'This is pointless and only adds a huge overhead for no gain at all.', 'Alternatively add a hard switch to disable loading of webfonts completely (there is the setting to use ""system font"" currently but it doesn\'t influence the behavior described above but loads webfonts nonetheless).', 'The third option is to finally accept and fix bug 46306 so users can decide themselves if they want webfonts to be downloaded or not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Actually the language names are shown fine without the need for additional fonts, that's how it worked for years now.",INVESTIGATION AND EXPLORATION,, 14666,ULS loads many webfonts needlessly on page load,"(In reply to comment #13) > I'm told this was partially fixed. > > (In reply to comment #9) > > I see few options: > > 1) do nothing > > 2) exclude those elements from webfonts (there is similar system as for input > > methods) > > 3) produce a special small font that contains all the glyphs needed to > > display > > all the native language names > > (2) was done, as far as I understand. I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>",1380200110,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #13) > I'm told this was partially fixed. > > (In reply to comment #9) > > I see few options: > > 1) do nothing > > 2) exclude those elements from webfonts (there is similar system as for input > > methods) > > 3) produce a special small font that contains all the glyphs needed to > > display > > all the native language names > > (2) was done, as far as I understand. I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>","(In reply to comment #13) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area.', 'This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>']",NA,0,(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area.,INVESTIGATION AND EXPLORATION,, 14666,ULS loads many webfonts needlessly on page load,"(In reply to comment #13) > I'm told this was partially fixed. > > (In reply to comment #9) > > I see few options: > > 1) do nothing > > 2) exclude those elements from webfonts (there is similar system as for input > > methods) > > 3) produce a special small font that contains all the glyphs needed to > > display > > all the native language names > > (2) was done, as far as I understand. I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>",1380200110,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #13) > I'm told this was partially fixed. > > (In reply to comment #9) > > I see few options: > > 1) do nothing > > 2) exclude those elements from webfonts (there is similar system as for input > > methods) > > 3) produce a special small font that contains all the glyphs needed to > > display > > all the native language names > > (2) was done, as far as I understand. I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>","(In reply to comment #13) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI found a more detailed explanation in the last [[mw:MLEB]] announcement: <20><>Web fonts are no longer loaded for autonyms in the interlanguage area.', 'This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>']",NA,0,This is a temporary change to improve performance; a more comprehensive fix may be done in the future.<2E><>,POTENTIAL NEW ISSUES AND REQUESTS,, 14667,ULS loads many webfonts needlessly on page load,"Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.",1379659385,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.","Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.']",NA,0,"Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.",ACTION ON ISSUE,, 14668,ULS loads many webfonts needlessly on page load,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.",1379659255,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.","I'm told this was partially fixed. (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE (2) was done, as far as I understand. <URL is the effect of <URL i.e. URL which deployed URL i.e. URL URL URL URL among which the commit(s) in question must be.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""I'm told this was partially fixed."", '(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.', '<URL is the effect of <URL i.e.', 'URL which deployed URL i.e.', 'URL\nURL\nURL\nURL\namong which the commit(s) in question must be.']",NA,0,"(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.",SOCIAL CONVERSATION,, 14668,ULS loads many webfonts needlessly on page load,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.",1379659255,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.","I'm told this was partially fixed. (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE (2) was done, as far as I understand. <URL is the effect of <URL i.e. URL which deployed URL i.e. URL URL URL URL among which the commit(s) in question must be.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""I'm told this was partially fixed."", '(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.', '<URL is the effect of <URL i.e.', 'URL which deployed URL i.e.', 'URL\nURL\nURL\nURL\namong which the commit(s) in question must be.']",NA,0,<URL is the effect of <URL i.e.,INVESTIGATION AND EXPLORATION,, 14668,ULS loads many webfonts needlessly on page load,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.",1379659255,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.","I'm told this was partially fixed. (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE (2) was done, as far as I understand. <URL is the effect of <URL i.e. URL which deployed URL i.e. URL URL URL URL among which the commit(s) in question must be.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""I'm told this was partially fixed."", '(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.', '<URL is the effect of <URL i.e.', 'URL which deployed URL i.e.', 'URL\nURL\nURL\nURL\namong which the commit(s) in question must be.']",NA,0,URL which deployed URL i.e.,INVESTIGATION AND EXPLORATION,, 14668,ULS loads many webfonts needlessly on page load,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.",1379659255,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.","I'm told this was partially fixed. (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE (2) was done, as far as I understand. <URL is the effect of <URL i.e. URL which deployed URL i.e. URL URL URL URL among which the commit(s) in question must be.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""I'm told this was partially fixed."", '(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.', '<URL is the effect of <URL i.e.', 'URL which deployed URL i.e.', 'URL\nURL\nURL\nURL\namong which the commit(s) in question must be.']",NA,0,URL\nURL\nURL\nURL\namong which the commit(s) in question must be.,INVESTIGATION AND EXPLORATION,, 14668,ULS loads many webfonts needlessly on page load,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.",1379659255,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I'm told this was partially fixed. (In reply to comment #9) > I see few options: > 1) do nothing > 2) exclude those elements from webfonts (there is similar system as for input > methods) > 3) produce a special small font that contains all the glyphs needed to > display > all the native language names (2) was done, as far as I understand. <https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium> is the effect of <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899> i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e. https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8 https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06 among which the commit(s) in question must be.","I'm told this was partially fixed. (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE (2) was done, as far as I understand. <URL is the effect of <URL i.e. URL which deployed URL i.e. URL URL URL URL among which the commit(s) in question must be.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""I'm told this was partially fixed."", '(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n(2) was done, as far as I understand.', '<URL is the effect of <URL i.e.', 'URL which deployed URL i.e.', 'URL\nURL\nURL\nURL\namong which the commit(s) in question must be.']",NA,0,I'm told this was partially fixed.,TASK PROGRESS,, 14669,ULS loads many webfonts needlessly on page load,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",1375821718,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.","I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.', 'Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.', ""Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either."", ""The proposed solution for bug 40874 won't solve the problem, though."", 'The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.']",NA,0,I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.,ACTION ON ISSUE,, 14669,ULS loads many webfonts needlessly on page load,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",1375821718,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.","I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.', 'Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.', ""Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either."", ""The proposed solution for bug 40874 won't solve the problem, though."", 'The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.']",NA,0,Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.,INVESTIGATION AND EXPLORATION,, 14669,ULS loads many webfonts needlessly on page load,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",1375821718,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.","I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.', 'Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.', ""Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either."", ""The proposed solution for bug 40874 won't solve the problem, though."", 'The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.']",NA,0,The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.,SOLUTION DISCUSSION,, 14669,ULS loads many webfonts needlessly on page load,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",1375821718,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.","I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.', 'Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.', ""Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either."", ""The proposed solution for bug 40874 won't solve the problem, though."", 'The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.']",NA,0,"Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either.",SOLUTION USAGE,, 14669,ULS loads many webfonts needlessly on page load,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",1375821718,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.","I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious. Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though. The easiest solution would still be to either - offer an option to completely disable ULS when the user knows he does not need it (bug 46306) - offer an option to easily disable all webfonts (bug 51102) To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.', 'Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates.', ""Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either."", ""The proposed solution for bug 40874 won't solve the problem, though."", 'The easiest solution would still be to either\n- offer an option to completely disable ULS when the user knows he does not need it (bug 46306)\n- offer an option to easily disable all webfonts (bug 51102)\n\nTo account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.']",NA,0,"The proposed solution for bug 40874 won't solve the problem, though.",SOLUTION DISCUSSION,, 14670,ULS loads many webfonts needlessly on page load,"Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***",1375774312,PHID-USER-w5a723w3wes6jd5wskgg,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***","Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['Going to dupe to bug 40874.', '*** This bug has been marked as a duplicate of bug 40874 ***']",NA,0,Going to dupe to bug 40874.,ISSUE CONTENT MANAGEMENT,, 14670,ULS loads many webfonts needlessly on page load,"Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***",1375774312,PHID-USER-w5a723w3wes6jd5wskgg,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***","Going to dupe to bug 40874. *** This bug has been marked as a duplicate of bug 40874 ***",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"['Going to dupe to bug 40874.', '*** This bug has been marked as a duplicate of bug 40874 ***']",NA,0,*** This bug has been marked as a duplicate of bug 40874 ***,ISSUE CONTENT MANAGEMENT,, 14671,ULS loads many webfonts needlessly on page load,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",1375772270,PHID-USER-w5a723w3wes6jd5wskgg,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.","We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"[""We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki."", 'This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS.', ""Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.""]",NA,0,"This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS.",SOLUTION DISCUSSION,, 14671,ULS loads many webfonts needlessly on page load,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",1375772270,PHID-USER-w5a723w3wes6jd5wskgg,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.","We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"[""We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki."", 'This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS.', ""Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.""]",NA,0,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki.",FUTURE PLANS,, 14671,ULS loads many webfonts needlessly on page load,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",1375772270,PHID-USER-w5a723w3wes6jd5wskgg,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.","We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS. Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-4,TRUE,"[""We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki."", 'This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS.', ""Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.""]",NA,0,"Tracked as URL No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.",CONTRIBUTION AND COMMITMENT,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,"I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).",SOLUTION DISCUSSION,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,Those would need continuous maintenance.,SOLUTION DISCUSSION,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,"I would prefer 1), since it is simplest and has the least amount of maintenance needed.",SOLUTION DISCUSSION,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,"If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).",WORKAROUND,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,I would dupe this to bug 50836.,ISSUE CONTENT MANAGEMENT,, 14672,ULS loads many webfonts needlessly on page load,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",1373486964,PHID-USER-732lqsmz4v6bss3kln2v,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.","I don't think there is consensus that loading webfonts for interlanguage links is always useless. I see few options: 1) do nothing 2) exclude those elements from webfonts (there is similar system as for input methods) 3) produce a special small font that contains all the glyphs needed to display all the native language names Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance. I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today). I would dupe this to bug 50836.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""I don't think there is consensus that loading webfonts for interlanguage links is always useless."", 'I see few options:\n1) do nothing\n2) exclude those elements from webfonts (there is similar system as for input methods)\n3) produce a special small font that contains all the glyphs needed to display all the native language names\n\nBoth 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.).', 'Those would need continuous maintenance.', 'I would prefer 1), since it is simplest and has the least amount of maintenance needed.', 'If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).', 'I would dupe this to bug 50836.']",NA,0,I don't think there is consensus that loading webfonts for interlanguage links is always useless.,SOLUTION DISCUSSION,, 14673,ULS loads many webfonts needlessly on page load,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",1373454230,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?","If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"['If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume.', 'Since I\'m not familiar with the implementation details of ULS:\nWould the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?']",NA,0,If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume.,SOLUTION DISCUSSION,, 14673,ULS loads many webfonts needlessly on page load,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",1373454230,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?","If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"['If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume.', 'Since I\'m not familiar with the implementation details of ULS:\nWould the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?']",NA,0,Since I\,NA,, 14673,ULS loads many webfonts needlessly on page load,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",1373454230,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?","If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume. Since I'm not familiar with the implementation details of ULS: Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"['If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume.', 'Since I\'m not familiar with the implementation details of ULS:\nWould the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang=""xy"" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?']",NA,0,xy,NA,, 14674,ULS loads many webfonts needlessly on page load,I see. Would the proposal in bug 51102 tackle most of this problem?,1373452570,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,I see. Would the proposal in bug 51102 tackle most of this problem?,I see. Would the proposal in bug 51102 tackle most of this problem?,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['I see.', 'Would the proposal in bug 51102 tackle most of this problem?']",NA,0,I see.,SOCIAL CONVERSATION,, 14674,ULS loads many webfonts needlessly on page load,I see. Would the proposal in bug 51102 tackle most of this problem?,1373452570,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,I see. Would the proposal in bug 51102 tackle most of this problem?,I see. Would the proposal in bug 51102 tackle most of this problem?,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['I see.', 'Would the proposal in bug 51102 tackle most of this problem?']",NA,0,Would the proposal in bug 51102 tackle most of this problem?,SOLUTION DISCUSSION,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,"turning of usage of webfonts completely as a user setting, or even solving bug 46306).",SOLUTION DISCUSSION,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,"2) There are also other cases were loading of webfonts would not be really necessary, e.g.",INVESTIGATION AND EXPLORATION,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,"pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.",SOLUTION USAGE,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,"3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.",ISSUE CONTENT MANAGEMENT,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,[1] URL,NA,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,"No, I think your proposed summary doesn't fit my concerns well.",ISSUE CONTENT MANAGEMENT,, 14675,ULS loads many webfonts needlessly on page load,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems",1373449439,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems","No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that: 1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306). 2) There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load. 3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug. [1] URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-7,TRUE,"[""No, I think your proposed summary doesn't fit my concerns well."", ""Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g."", 'turning of usage of webfonts completely as a user setting, or even solving bug 46306).', '2) There are also other cases were loading of webfonts would not be really necessary, e.g.', 'pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.', '3) Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.', '[1] URL']",NA,0,Actually I have several reasons for that:\n1) As pointed out I'd also be happy (if not happier) with a more general solution (e.g.,SOLUTION DISCUSSION,, 14676,ULS loads many webfonts needlessly on page load,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",1373447925,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).","(In reply to comment #0) QUOTE QUOTE I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.', 'displayed for some rather exotic languages/scripts, so I\'m not sure if the loading is really ""needless"" if those are now displayed correctly.', 'If I get you correctly, I\'m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \'Other languages\' list"" (which would enhance funtionality and turn this into an enhancement request).']",NA,0,(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.,SOLUTION DISCUSSION,, 14676,ULS loads many webfonts needlessly on page load,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",1373447925,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).","(In reply to comment #0) QUOTE QUOTE I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.', 'displayed for some rather exotic languages/scripts, so I\'m not sure if the loading is really ""needless"" if those are now displayed correctly.', 'If I get you correctly, I\'m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \'Other languages\' list"" (which would enhance funtionality and turn this into an enhancement request).']",NA,0,"displayed for some rather exotic languages/scripts, so I\",INVESTIGATION AND EXPLORATION,, 14676,ULS loads many webfonts needlessly on page load,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",1373447925,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).","(In reply to comment #0) QUOTE QUOTE I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.', 'displayed for some rather exotic languages/scripts, so I\'m not sure if the loading is really ""needless"" if those are now displayed correctly.', 'If I get you correctly, I\'m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \'Other languages\' list"" (which would enhance funtionality and turn this into an enhancement request).']",NA,0,"m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \",ACTION ON ISSUE,, 14676,ULS loads many webfonts needlessly on page load,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",1373447925,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).","(In reply to comment #0) QUOTE QUOTE I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.', 'displayed for some rather exotic languages/scripts, so I\'m not sure if the loading is really ""needless"" if those are now displayed correctly.', 'If I get you correctly, I\'m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \'Other languages\' list"" (which would enhance funtionality and turn this into an enhancement request).']",NA,0," list"" (which would enhance funtionality and turn this into an enhancement request).",ACTION ON ISSUE,, 14676,ULS loads many webfonts needlessly on page load,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",1373447925,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #0) > Actually the language names are shown fine without the need for > additional fonts, that's how it worked for years now. I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).","(In reply to comment #0) QUOTE QUOTE I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really ""needless"" if those are now displayed correctly. If I get you correctly, I'm tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the 'Other languages' list"" (which would enhance funtionality and turn this into an enhancement request).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-7,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\n\nI can imagine that this would be the statement to be challenged - I always had some squares etc.', 'displayed for some rather exotic languages/scripts, so I\'m not sure if the loading is really ""needless"" if those are now displayed correctly.', 'If I get you correctly, I\'m tempted to change the bug summary from ""ULS loads many webfonts needlessly on page load"" to ""ULS should not load webfonts only because of entries in the \'Other languages\' list"" (which would enhance funtionality and turn this into an enhancement request).']",NA,0,needless,NA,, 14677,ULS loads many webfonts needlessly on page load,"(In reply to comment #3) > Have you read comment 1 Nemo? Not before writing mine; I had a mid-air collision, as timestamp hints. > I explicitly stated it is *not* a duplicate of > those bugs. That's not enough to actually *make* it not a duplicate ;) but devs will know.",1373408705,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #3) > Have you read comment 1 Nemo? Not before writing mine; I had a mid-air collision, as timestamp hints. > I explicitly stated it is *not* a duplicate of > those bugs. That's not enough to actually *make* it not a duplicate ;) but devs will know.","(In reply to comment #3) QUOTE Not before writing mine; I had a mid-air collision, as timestamp hints. QUOTE QUOTE That's not enough to actually *make* it not a duplicate ;) but devs will know.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['(In reply to comment #3)\nQUOTE\n\nNot before writing mine; I had a mid-air collision, as timestamp hints.', ""QUOTE\nQUOTE\n\nThat's not enough to actually *make* it not a duplicate ;) but devs will know.""]",NA,0,"(In reply to comment #3)\nQUOTE\n\nNot before writing mine; I had a mid-air collision, as timestamp hints.",SOCIAL CONVERSATION,, 14677,ULS loads many webfonts needlessly on page load,"(In reply to comment #3) > Have you read comment 1 Nemo? Not before writing mine; I had a mid-air collision, as timestamp hints. > I explicitly stated it is *not* a duplicate of > those bugs. That's not enough to actually *make* it not a duplicate ;) but devs will know.",1373408705,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"(In reply to comment #3) > Have you read comment 1 Nemo? Not before writing mine; I had a mid-air collision, as timestamp hints. > I explicitly stated it is *not* a duplicate of > those bugs. That's not enough to actually *make* it not a duplicate ;) but devs will know.","(In reply to comment #3) QUOTE Not before writing mine; I had a mid-air collision, as timestamp hints. QUOTE QUOTE That's not enough to actually *make* it not a duplicate ;) but devs will know.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['(In reply to comment #3)\nQUOTE\n\nNot before writing mine; I had a mid-air collision, as timestamp hints.', ""QUOTE\nQUOTE\n\nThat's not enough to actually *make* it not a duplicate ;) but devs will know.""]",NA,0,QUOTE\nQUOTE\n\nThat's not enough to actually *make* it not a duplicate ;) but devs will know.,ISSUE CONTENT MANAGEMENT,, 14678,ULS loads many webfonts needlessly on page load,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",1373407873,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).","Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Have you read comment 1 Nemo?', 'I explicitly stated it is *not* a duplicate of those bugs.', 'The linked bugs are about optimizing performance of loading of webfonts.', 'This bug is about not loading them at all if not necessary.', ""While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).""]",NA,0,Have you read comment 1 Nemo?,SOCIAL CONVERSATION,, 14678,ULS loads many webfonts needlessly on page load,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",1373407873,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).","Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Have you read comment 1 Nemo?', 'I explicitly stated it is *not* a duplicate of those bugs.', 'The linked bugs are about optimizing performance of loading of webfonts.', 'This bug is about not loading them at all if not necessary.', ""While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).""]",NA,0,I explicitly stated it is *not* a duplicate of those bugs.,ISSUE CONTENT MANAGEMENT,, 14678,ULS loads many webfonts needlessly on page load,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",1373407873,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).","Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Have you read comment 1 Nemo?', 'I explicitly stated it is *not* a duplicate of those bugs.', 'The linked bugs are about optimizing performance of loading of webfonts.', 'This bug is about not loading them at all if not necessary.', ""While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).""]",NA,0,The linked bugs are about optimizing performance of loading of webfonts.,ISSUE CONTENT MANAGEMENT,, 14678,ULS loads many webfonts needlessly on page load,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",1373407873,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).","Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Have you read comment 1 Nemo?', 'I explicitly stated it is *not* a duplicate of those bugs.', 'The linked bugs are about optimizing performance of loading of webfonts.', 'This bug is about not loading them at all if not necessary.', ""While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).""]",NA,0,This bug is about not loading them at all if not necessary.,ISSUE CONTENT MANAGEMENT,, 14678,ULS loads many webfonts needlessly on page load,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",1373407873,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).","Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs. The linked bugs are about optimizing performance of loading of webfonts. This bug is about not loading them at all if not necessary. While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Have you read comment 1 Nemo?', 'I explicitly stated it is *not* a duplicate of those bugs.', 'The linked bugs are about optimizing performance of loading of webfonts.', 'This bug is about not loading them at all if not necessary.', ""While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).""]",NA,0,"While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).",SOLUTION DISCUSSION,, 14679,ULS loads many webfonts needlessly on page load,"This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.",1373407021,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.","This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.']",NA,0,"This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.",ISSUE CONTENT MANAGEMENT,, 14680,ULS loads many webfonts needlessly on page load,"Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!",1373406977,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!","Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same!', ""They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!""]",NA,0,"Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same!",ISSUE CONTENT MANAGEMENT,, 14680,ULS loads many webfonts needlessly on page load,"Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!",1373406977,PHID-USER-v3yn5qf233ggnnnmvejc,PHID-TASK-u2gugtsvvbac5ylrii64,task_subcomment,"Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!","Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-8,TRUE,"['Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same!', ""They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!""]",NA,0,They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!,SOLUTION DISCUSSION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,Allow login using mosh as an alternative to plain ssh on bastion.,SOLUTION DISCUSSION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,ssh is quite painful over a slow and/or lossy connection.,OBSERVED BUG BEHAVIOR,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.",INVESTIGATION AND EXPLORATION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).",INVESTIGATION AND EXPLORATION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.",INVESTIGATION AND EXPLORATION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"mosh uses ssh for authentication and then changes to it's own robust, udp based protocol.",INVESTIGATION AND EXPLORATION,, 14976,Allow login using mosh as an alternative to plain ssh on bastion,"ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",1376117100,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_description,"Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement","Allow login using mosh as an alternative to plain ssh on bastion./n/nssh is quite painful over a slow and/or lossy connection. mosh uses ssh for authentication and then changes to it's own robust, udp based protocol. Quoting from the man page: mosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD> vides speculative local echo and line editing of user keystrokes. Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD> and more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD> ately, without waiting for a network round-trip. mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key authentication or a password). mosh executes the unprivileged mosh-server helper program on the server, then closes the SSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP. -------------------------- **Version**: unspecified **Severity**: enhancement",Lowest,10,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,invalid,TRUE,c2,2,FALSE,FALSE,-3,TRUE,"['Allow login using mosh as an alternative to plain ssh on bastion.', 'ssh is quite painful over a slow and/or lossy connection.', ""mosh uses ssh for authentication and then changes to it's own robust, udp based protocol."", 'Quoting from the man page:\n\nmosh (mobile shell) is a remote terminal application that supports intermittent connectivity, allows roaming, and pro<72><6F><EFBFBD>\nvides speculative local echo and line editing of user keystrokes.', ""Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip."", 'mosh uses ssh to establish a connection to the remote host and authenticate with existing means (e.g., public-key\nauthentication or a password).', 'mosh executes the unprivileged mosh-server helper program on the server, then closes the\nSSH connection and starts the mosh-client, which establishes a long-lived datagram connection over UDP.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Compared with ssh, mosh is more robust <20><><EFBFBD> its connections stay up across sleeps and changes in the client's IP address <20><><EFBFBD>\nand more responsive, because the protocol is tolerant of packet loss and the client can echo most keystrokes immedi<64><69><EFBFBD>\nately, without waiting for a network round-trip.",INVESTIGATION AND EXPLORATION,, 14977,Allow login using mosh as an alternative to plain ssh on bastion,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,131,TRUE,"[""I am tossing this for now since mosh doesn't support the methodology used by labs in general."", ""What can be done was done but it's not very useful.""]",NA,0,I am tossing this for now since mosh doesn't support the methodology used by labs in general.,ACTION ON ISSUE,, 14977,Allow login using mosh as an alternative to plain ssh on bastion,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,1456949493,PHID-USER-3neel27i7dyu62jbbx2l,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,I am tossing this for now since mosh doesn't support the methodology used by labs in general. What can be done was done but it's not very useful.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,131,TRUE,"[""I am tossing this for now since mosh doesn't support the methodology used by labs in general."", ""What can be done was done but it's not very useful.""]",NA,0,What can be done was done but it's not very useful.,SOLUTION USAGE,, 14978,Allow login using mosh as an alternative to plain ssh on bastion,"Still not merged, so we can't really do much.",1413537437,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Still not merged, so we can't really do much.","Still not merged, so we can't really do much.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,59,TRUE,"[""Still not merged, so we can't really do much.""]",NA,0,"Still not merged, so we can't really do much.",TASK PROGRESS,, 14979,Allow login using mosh as an alternative to plain ssh on bastion,"Considering we are dealing with keys, *definitely* the former!",1380191281,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Considering we are dealing with keys, *definitely* the former!","Considering we are dealing with keys, *definitely* the former!",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Considering we are dealing with keys, *definitely* the former!']",NA,0,"Considering we are dealing with keys, *definitely* the former!",SOCIAL CONVERSATION,, 14980,Allow login using mosh as an alternative to plain ssh on bastion,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",1380191249,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D","I checked out URL and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['I checked out URL and that actually works!', 'So either that gets merged, or we make a patched package.', 'Hopefully the former :D']",NA,0,I checked out URL and that actually works!,BUG REPRODUCTION,, 14980,Allow login using mosh as an alternative to plain ssh on bastion,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",1380191249,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D","I checked out URL and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['I checked out URL and that actually works!', 'So either that gets merged, or we make a patched package.', 'Hopefully the former :D']",NA,0,"So either that gets merged, or we make a patched package.",FUTURE PLANS,, 14980,Allow login using mosh as an alternative to plain ssh on bastion,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",1380191249,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"I checked out http://mailman.mit.edu/pipermail/mosh-devel/2013-May/000499.html and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D","I checked out URL and that actually works! So either that gets merged, or we make a patched package. Hopefully the former :D",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['I checked out URL and that actually works!', 'So either that gets merged, or we make a patched package.', 'Hopefully the former :D']",NA,0,Hopefully the former :D,SOCIAL CONVERSATION,, 14981,Allow login using mosh as an alternative to plain ssh on bastion,"Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...",1380176994,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...","Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Yeah, and you want mosh in client -> bastion, since that is the flaky part.', ""If you need mosh from bastion to target host, you've bigger problems...""]",NA,0,"Yeah, and you want mosh in client -> bastion, since that is the flaky part.",SOLUTION DISCUSSION,, 14981,Allow login using mosh as an alternative to plain ssh on bastion,"Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...",1380176994,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...","Yeah, and you want mosh in client -> bastion, since that is the flaky part. If you need mosh from bastion to target host, you've bigger problems...",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['Yeah, and you want mosh in client -> bastion, since that is the flaky part.', ""If you need mosh from bastion to target host, you've bigger problems...""]",NA,0,"If you need mosh from bastion to target host, you've bigger problems...",SOCIAL CONVERSATION,, 14982,Allow login using mosh as an alternative to plain ssh on bastion,"mosh is indeed only reasonably useful for instances with a public IP: while you can proxycommand the mosh invocation itself, your local client won't be able to connect to the started mosh-server unless it is reachable.",1380137483,PHID-USER-h75guknmwivm6x37iute,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"mosh is indeed only reasonably useful for instances with a public IP: while you can proxycommand the mosh invocation itself, your local client won't be able to connect to the started mosh-server unless it is reachable.","mosh is indeed only reasonably useful for instances with a public IP: while you can proxycommand the mosh invocation itself, your local client won't be able to connect to the started mosh-server unless it is reachable.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,4,TRUE,"[""mosh is indeed only reasonably useful for instances with a public IP: while you can proxycommand the mosh invocation itself, your local client won't be able to connect to the started mosh-server unless it is reachable.""]",NA,0,"mosh is indeed only reasonably useful for instances with a public IP: while you can proxycommand the mosh invocation itself, your local client won't be able to connect to the started mosh-server unless it is reachable.",SOLUTION USAGE,, 14983,Allow login using mosh as an alternative to plain ssh on bastion,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",1380136951,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(","We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions!', ""However....\n\nBecause of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs."", 'So we can mosh to the bastion, and... that is pretty much it.', 'Quite useless, IMO :(']",NA,0,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions!",SOLUTION USAGE,, 14983,Allow login using mosh as an alternative to plain ssh on bastion,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",1380136951,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(","We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions!', ""However....\n\nBecause of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs."", 'So we can mosh to the bastion, and... that is pretty much it.', 'Quite useless, IMO :(']",NA,0,"So we can mosh to the bastion, and... that is pretty much it.",SOLUTION USAGE,, 14983,Allow login using mosh as an alternative to plain ssh on bastion,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",1380136951,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(","We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions!', ""However....\n\nBecause of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs."", 'So we can mosh to the bastion, and... that is pretty much it.', 'Quite useless, IMO :(']",NA,0,"Quite useless, IMO :(",SOCIAL CONVERSATION,, 14983,Allow login using mosh as an alternative to plain ssh on bastion,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",1380136951,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(","We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions! However.... Because of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs. So we can mosh to the bastion, and... that is pretty much it. Quite useless, IMO :(",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,4,TRUE,"['We now have mosh installed on the labs bastions (and Coren graciously opened up the relevant ports), and can mosh to the bastions!', ""However....\n\nBecause of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs."", 'So we can mosh to the bastion, and... that is pretty much it.', 'Quite useless, IMO :(']",NA,0,"However....\n\nBecause of mosh's lack of support for proxycommand or equivalent, we can't really use bastions to access the rest of labs.",SOLUTION USAGE,, 14984,Allow login using mosh as an alternative to plain ssh on bastion,"Change 84105 merged by Akosiaris: Add mosh to labs bastions https://gerrit.wikimedia.org/r/84105",1379355551,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Change 84105 merged by Akosiaris: Add mosh to labs bastions https://gerrit.wikimedia.org/r/84105","Change 84105 merged by Akosiaris: Add mosh to labs bastions GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,2,TRUE,['Change 84105 merged by Akosiaris:\nAdd mosh to labs bastions\n\nGERRIT_URL'],NA,0,Change 84105 merged by Akosiaris:\nAdd mosh to labs bastions\n\nGERRIT_URL,TASK PROGRESS,, 14985,Allow login using mosh as an alternative to plain ssh on bastion,"Change 84105 had a related patch set uploaded by Yuvipanda: Add mosh to labs bastions https://gerrit.wikimedia.org/r/84105",1379029401,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Change 84105 had a related patch set uploaded by Yuvipanda: Add mosh to labs bastions https://gerrit.wikimedia.org/r/84105","Change 84105 had a related patch set uploaded by Yuvipanda: Add mosh to labs bastions GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,2,TRUE,['Change 84105 had a related patch set uploaded by Yuvipanda:\nAdd mosh to labs bastions\n\nGERRIT_URL'],NA,0,Change 84105 had a related patch set uploaded by Yuvipanda:\nAdd mosh to labs bastions\n\nGERRIT_URL,TASK PROGRESS,, 14986,Allow login using mosh as an alternative to plain ssh on bastion,"Change 84024 merged by coren: Add mosh to bastion hosts https://gerrit.wikimedia.org/r/84024",1379028202,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Change 84024 merged by coren: Add mosh to bastion hosts https://gerrit.wikimedia.org/r/84024","Change 84024 merged by coren: Add mosh to bastion hosts GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,2,TRUE,['Change 84024 merged by coren:\nAdd mosh to bastion hosts\n\nGERRIT_URL'],NA,0,Change 84024 merged by coren:\nAdd mosh to bastion hosts\n\nGERRIT_URL,TASK PROGRESS,, 14987,Allow login using mosh as an alternative to plain ssh on bastion,https://gerrit.wikimedia.org/r/#/c/84024/ perhaps? Not sure if we need to open up any ports or just installing the package is enough?,1379011169,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,https://gerrit.wikimedia.org/r/#/c/84024/ perhaps? Not sure if we need to open up any ports or just installing the package is enough?,URL perhaps? Not sure if we need to open up any ports or just installing the package is enough?,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,2,TRUE,"['URL perhaps?', 'Not sure if we need to open up any ports or just installing the package is enough?']",NA,0,URL perhaps?,NA,, 14987,Allow login using mosh as an alternative to plain ssh on bastion,https://gerrit.wikimedia.org/r/#/c/84024/ perhaps? Not sure if we need to open up any ports or just installing the package is enough?,1379011169,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,https://gerrit.wikimedia.org/r/#/c/84024/ perhaps? Not sure if we need to open up any ports or just installing the package is enough?,URL perhaps? Not sure if we need to open up any ports or just installing the package is enough?,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,2,TRUE,"['URL perhaps?', 'Not sure if we need to open up any ports or just installing the package is enough?']",NA,0,Not sure if we need to open up any ports or just installing the package is enough?,SOLUTION DISCUSSION,, 14988,Allow login using mosh as an alternative to plain ssh on bastion,"Change 84024 had a related patch set uploaded by Yuvipanda: Add mosh to bastion hosts https://gerrit.wikimedia.org/r/84024",1379011106,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Change 84024 had a related patch set uploaded by Yuvipanda: Add mosh to bastion hosts https://gerrit.wikimedia.org/r/84024","Change 84024 had a related patch set uploaded by Yuvipanda: Add mosh to bastion hosts GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,2,TRUE,['Change 84024 had a related patch set uploaded by Yuvipanda:\nAdd mosh to bastion hosts\n\nGERRIT_URL'],NA,0,Change 84024 had a related patch set uploaded by Yuvipanda:\nAdd mosh to bastion hosts\n\nGERRIT_URL,TASK PROGRESS,, 14989,Allow login using mosh as an alternative to plain ssh on bastion,*** Bug 49454 has been marked as a duplicate of this bug. ***,1379011061,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,*** Bug 49454 has been marked as a duplicate of this bug. ***,*** Bug 49454 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,2,TRUE,"['*** Bug 49454 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 49454 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 14989,Allow login using mosh as an alternative to plain ssh on bastion,*** Bug 49454 has been marked as a duplicate of this bug. ***,1379011061,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,*** Bug 49454 has been marked as a duplicate of this bug. ***,*** Bug 49454 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,2,TRUE,"['*** Bug 49454 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 14990,Allow login using mosh as an alternative to plain ssh on bastion,"JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.",1376245807,PHID-USER-vk6mlmacfhx77egryy5i,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.","JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-3,TRUE,"['JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen.', ""Labs bastions could certainly handle that but it's something to keep in mind.""]",NA,0,"JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen.",SOLUTION DISCUSSION,, 14990,Allow login using mosh as an alternative to plain ssh on bastion,"JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.",1376245807,PHID-USER-vk6mlmacfhx77egryy5i,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.","JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen. Labs bastions could certainly handle that but it's something to keep in mind.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-3,TRUE,"['JFTR, on Tools mosh-server processes eat up to 25 MBytes RSS each; sshds usually are much lighter, even if you add screen.', ""Labs bastions could certainly handle that but it's something to keep in mind.""]",NA,0,Labs bastions could certainly handle that but it's something to keep in mind.,SOLUTION DISCUSSION,, 14991,Allow login using mosh as an alternative to plain ssh on bastion,"This is supported on tools, but adding it to the general bastions would be a good idea.",1376185312,PHID-USER-h75guknmwivm6x37iute,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"This is supported on tools, but adding it to the general bastions would be a good idea.","This is supported on tools, but adding it to the general bastions would be a good idea.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-3,TRUE,"['This is supported on tools, but adding it to the general bastions would be a good idea.']",NA,0,"This is supported on tools, but adding it to the general bastions would be a good idea.",SOLUTION DISCUSSION,, 14992,Allow login using mosh as an alternative to plain ssh on bastion,"Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.",1376118400,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.","Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-3,TRUE,"['Just found out that mosh already works for tools-login, just not for bastion.', 'would still be nice to have that, too.']",NA,0,"Just found out that mosh already works for tools-login, just not for bastion.",SOLUTION USAGE,, 14992,Allow login using mosh as an alternative to plain ssh on bastion,"Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.",1376118400,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.","Just found out that mosh already works for tools-login, just not for bastion. would still be nice to have that, too.",NA,NA,NA,NA,NA,TRUE,c2,2,FALSE,NA,-3,TRUE,"['Just found out that mosh already works for tools-login, just not for bastion.', 'would still be nice to have that, too.']",NA,0,"would still be nice to have that, too.",SOCIAL CONVERSATION,, 14993,Allow login using mosh as an alternative to plain ssh on bastion,"(In reply to comment #0) > ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for > authentication and then changes to it's own robust, udp based protocol. Robust and udp in the same sentence sounds funny",1376118251,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-hnwvtmwgpm2oisoqaozt,task_subcomment,"(In reply to comment #0) > ssh is quite painful over a slow and/or lossy connection. mosh uses ssh for > authentication and then changes to it's own robust, udp based protocol. Robust and udp in the same sentence sounds funny","(In reply to comment #0) QUOTE QUOTE Robust and udp in the same sentence sounds funny",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-3,TRUE,['(In reply to comment #0)\nQUOTE\nQUOTE\n\nRobust and udp in the same sentence sounds funny'],NA,0,(In reply to comment #0)\nQUOTE\nQUOTE\n\nRobust and udp in the same sentence sounds funny,SOCIAL CONVERSATION,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Automatic account creation on manual login not logged in newusers log.,SOLUTION USAGE,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.",BUG REPRODUCTION,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,"On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].",OBSERVED BUG BEHAVIOR,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Please log this automatically account creation on manually login also in the newusers log.,EXPECTED BEHAVIOR,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,Thanks.,SOCIAL CONVERSATION,, 15061,Automatic account creation on manual login not logged in newusers log,"My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",1353870240,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_description,"Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical","Automatic account creation on manual login not logged in newusers log./n/nMy browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org. On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]]. Please log this automatically account creation on manually login also in the newusers log. Thanks. -------------------------- **Version**: unspecified **Severity**: critical",Unbreak Now!,100,1369394696,NA,resolved,TRUE,c2,1,FALSE,FALSE,-40,TRUE,"['Automatic account creation on manual login not logged in newusers log.', 'My browser has cookies from third parties disabled and than I am not logged in automatically with CentralAuth/SUL, when visited, for example, wikidata.org.', 'On my first visit on wikidata.org I have manually logged in over [[d:Special:UserLogin]] and my account was created automatically, but this account creation is not logged in the newusers log [[d:Special:Log/newusers/Umherirrender]].', 'Please log this automatically account creation on manually login also in the newusers log.', 'Thanks.', '--------------------------\n**Version**: unspecified\n**Severity**: critical']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: critical,OBSERVED BUG BEHAVIOR,, 15062,Automatic account creation on manual login not logged in newusers log,"successfully merged, thanks for your work!",1369394696,PHID-USER-qaoxfiqu6bxhd5ehlwhc,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,"successfully merged, thanks for your work!","successfully merged, thanks for your work!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-14,TRUE,"['successfully merged, thanks for your work!']",NA,0,"successfully merged, thanks for your work!",SOCIAL CONVERSATION,, 15063,Automatic account creation on manual login not logged in newusers log,Related URL: https://gerrit.wikimedia.org/r/65123 (Gerrit Change I772cf0e7470a6111f84135074014e8a5f8c5fde0),1369319601,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/65123 (Gerrit Change I772cf0e7470a6111f84135074014e8a5f8c5fde0),Related URL: GERRIT_URL (Gerrit Change I772cf0e7470a6111f84135074014e8a5f8c5fde0),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-14,TRUE,['Related URL: GERRIT_URL (Gerrit Change I772cf0e7470a6111f84135074014e8a5f8c5fde0)'],NA,0,Related URL: GERRIT_URL (Gerrit Change I772cf0e7470a6111f84135074014e8a5f8c5fde0),ISSUE CONTENT MANAGEMENT,, 15064,Automatic account creation on manual login not logged in newusers log,Adding Hoo also. I'll try and take a look at it this week.,1369316385,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Adding Hoo also. I'll try and take a look at it this week.,Adding Hoo also. I'll try and take a look at it this week.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-14,TRUE,"['Adding Hoo also.', ""I'll try and take a look at it this week.""]",NA,0,Adding Hoo also.,ACTION ON ISSUE,, 15064,Automatic account creation on manual login not logged in newusers log,Adding Hoo also. I'll try and take a look at it this week.,1369316385,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Adding Hoo also. I'll try and take a look at it this week.,Adding Hoo also. I'll try and take a look at it this week.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-14,TRUE,"['Adding Hoo also.', ""I'll try and take a look at it this week.""]",NA,0,I'll try and take a look at it this week.,CONTRIBUTION AND COMMITMENT,, 15065,Automatic account creation on manual login not logged in newusers log,Andrew / Greg: Any idea who could take a look at this issue?,1369251139,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Andrew / Greg: Any idea who could take a look at this issue?,Andrew / Greg: Any idea who could take a look at this issue?,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-14,TRUE,['Andrew / Greg: Any idea who could take a look at this issue?'],NA,0,Andrew / Greg: Any idea who could take a look at this issue?,CONTRIBUTION AND COMMITMENT,, 15066,Automatic account creation on manual login not logged in newusers log,Bumping priority significantly; this is a real mess.,1367525894,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Bumping priority significantly; this is a real mess.,Bumping priority significantly; this is a real mess.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,['Bumping priority significantly; this is a real mess.'],NA,0,Bumping priority significantly; this is a real mess.,ACTION ON ISSUE,, 15067,Automatic account creation on manual login not logged in newusers log,Confirmed on my local dev. Yuk. That needs to get fixed.,1367524953,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Confirmed on my local dev. Yuk. That needs to get fixed.,Confirmed on my local dev. Yuk. That needs to get fixed.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,"['Confirmed on my local dev.', 'Yuk.', 'That needs to get fixed.']",NA,0,Confirmed on my local dev.,BUG REPRODUCTION,, 15067,Automatic account creation on manual login not logged in newusers log,Confirmed on my local dev. Yuk. That needs to get fixed.,1367524953,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Confirmed on my local dev. Yuk. That needs to get fixed.,Confirmed on my local dev. Yuk. That needs to get fixed.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,"['Confirmed on my local dev.', 'Yuk.', 'That needs to get fixed.']",NA,0,Yuk.,SOCIAL CONVERSATION,, 15067,Automatic account creation on manual login not logged in newusers log,Confirmed on my local dev. Yuk. That needs to get fixed.,1367524953,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,Confirmed on my local dev. Yuk. That needs to get fixed.,Confirmed on my local dev. Yuk. That needs to get fixed.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,"['Confirmed on my local dev.', 'Yuk.', 'That needs to get fixed.']",NA,0,That needs to get fixed.,MOTIVATION,, 15068,Automatic account creation on manual login not logged in newusers log,*** Bug 48015 has been marked as a duplicate of this bug. ***,1367524364,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,*** Bug 48015 has been marked as a duplicate of this bug. ***,*** Bug 48015 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,"['*** Bug 48015 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 48015 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 15068,Automatic account creation on manual login not logged in newusers log,*** Bug 48015 has been marked as a duplicate of this bug. ***,1367524364,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-cr2twskhtr4untkis7m5,task_subcomment,*** Bug 48015 has been marked as a duplicate of this bug. ***,*** Bug 48015 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-17,TRUE,"['*** Bug 48015 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 15196,Persona Login,"**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement",1361428140,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-64j72hiqkmcxn2sfxgct,task_description,"Persona Login./n/n**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement","Persona Login./n/n**Author:** CODE **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <URL -------------------------- **Version**: unspecified **Severity**: enhancement",Needs Triage,90,1361453228,NA,invalid,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['Persona Login.', '**Author:** CODE\n\n**Description:**\nAllow users to log in with Persona instead of having to create a new account.', 'Some documentation on persona and how to integrate it can be found at: <URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,Persona Login.,NA,, 15196,Persona Login,"**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement",1361428140,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-64j72hiqkmcxn2sfxgct,task_description,"Persona Login./n/n**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement","Persona Login./n/n**Author:** CODE **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <URL -------------------------- **Version**: unspecified **Severity**: enhancement",Needs Triage,90,1361453228,NA,invalid,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['Persona Login.', '**Author:** CODE\n\n**Description:**\nAllow users to log in with Persona instead of having to create a new account.', 'Some documentation on persona and how to integrate it can be found at: <URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,**Author:** CODE\n\n**Description:**\nAllow users to log in with Persona instead of having to create a new account.,EXPECTED BEHAVIOR,, 15196,Persona Login,"**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement",1361428140,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-64j72hiqkmcxn2sfxgct,task_description,"Persona Login./n/n**Author:** `wikimedia-bugs` **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <https://developer.mozilla.org/en-US/docs/Persona>. -------------------------- **Version**: unspecified **Severity**: enhancement","Persona Login./n/n**Author:** CODE **Description:** Allow users to log in with Persona instead of having to create a new account. Some documentation on persona and how to integrate it can be found at: <URL -------------------------- **Version**: unspecified **Severity**: enhancement",Needs Triage,90,1361453228,NA,invalid,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['Persona Login.', '**Author:** CODE\n\n**Description:**\nAllow users to log in with Persona instead of having to create a new account.', 'Some documentation on persona and how to integrate it can be found at: <URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,Some documentation on persona and how to integrate it can be found at: <URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 15197,Persona Login,We already have an extension for this it seems: https://www.mediawiki.org/wiki/Extension:Persona,1361453228,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-64j72hiqkmcxn2sfxgct,task_subcomment,We already have an extension for this it seems: https://www.mediawiki.org/wiki/Extension:Persona,We already have an extension for this it seems: URL,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-27,TRUE,['We already have an extension for this it seems: URL'],NA,0,We already have an extension for this it seems: URL,SOLUTION DISCUSSION,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"""https services"" listed as unsupported at status.wikimedia.org.",OBSERVED BUG BEHAVIOR,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"Currently an entry at <URL reads ""https services (unsupported)"".",OBSERVED BUG BEHAVIOR,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"I think the ""(unsupported)"" part is off-the-mark and should be removed.",EXPECTED BEHAVIOR,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"Maybe it could be changed to ""experimental"" or ""beta"" or something?",SOLUTION DISCUSSION,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL,OBSERVED BUG BEHAVIOR,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"I don't think any qualifier is needed, though.",SOLUTION DISCUSSION,, 15310,"""https services"" listed as unsupported at status.wikimedia.org","Currently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/",1344918840,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_description,"""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <http://status.wikimedia.org/> reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://status.wikimedia.org/","""https services"" listed as unsupported at status.wikimedia.org./n/nCurrently an entry at <URL reads ""https services (unsupported)"". I think the ""(unsupported)"" part is off-the-mark and should be removed. Maybe it could be changed to ""experimental"" or ""beta"" or something? I don't think any qualifier is needed, though. I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that. -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL",Needs Triage,90,1355931241,NA,resolved,TRUE,c2,1,TRUE,FALSE,-55,TRUE,"['""https services"" listed as unsupported at status.wikimedia.org.', 'Currently an entry at <URL reads ""https services (unsupported)"".', 'I think the ""(unsupported)"" part is off-the-mark and should be removed.', 'Maybe it could be changed to ""experimental"" or ""beta"" or something?', ""I don't think any qualifier is needed, though."", ""I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"I also considered that maybe it was referring to secure.wikimedia.org (which is pretty much unsupported), but I don't see any evidence of that.",INVESTIGATION AND EXPLORATION,, 15311,"""https services"" listed as unsupported at status.wikimedia.org","Does not say (unsupported) anymore, closing as FIXED.",1355931241,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-s7zbdnwrfyooz3km7gv7,task_subcomment,"Does not say (unsupported) anymore, closing as FIXED.","Does not say (unsupported) anymore, closing as FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-36,TRUE,"['Does not say (unsupported) anymore, closing as FIXED.']",NA,0,"Does not say (unsupported) anymore, closing as FIXED.",ACTION ON ISSUE,, 15322,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter","When being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",1341777180,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4yxpk2dzj5i44ge226gc,task_description,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major","[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: URL And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",Needs Triage,90,1341777207,NA,resolved,TRUE,c2,1,TRUE,FALSE,-60,TRUE,"['[Regression] ""returnto"" from Login broken when used from a page without \'title\' parameter.', 'When being logged out and using a link from Recentchanges like this:\n\nURL\n\nAnd then trying to log in, it will return to ""Main Page"".', '--------------------------\n**Version**: 1.19\n**Severity**: major']",TRUE,0,"[Regression] ""returnto"" from Login broken when used from a page without \",OBSERVED BUG BEHAVIOR,, 15322,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter","When being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",1341777180,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4yxpk2dzj5i44ge226gc,task_description,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major","[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: URL And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",Needs Triage,90,1341777207,NA,resolved,TRUE,c2,1,TRUE,FALSE,-60,TRUE,"['[Regression] ""returnto"" from Login broken when used from a page without \'title\' parameter.', 'When being logged out and using a link from Recentchanges like this:\n\nURL\n\nAnd then trying to log in, it will return to ""Main Page"".', '--------------------------\n**Version**: 1.19\n**Severity**: major']",TRUE,0, parameter.,NA,, 15322,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter","When being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",1341777180,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4yxpk2dzj5i44ge226gc,task_description,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major","[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: URL And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",Needs Triage,90,1341777207,NA,resolved,TRUE,c2,1,TRUE,FALSE,-60,TRUE,"['[Regression] ""returnto"" from Login broken when used from a page without \'title\' parameter.', 'When being logged out and using a link from Recentchanges like this:\n\nURL\n\nAnd then trying to log in, it will return to ""Main Page"".', '--------------------------\n**Version**: 1.19\n**Severity**: major']",TRUE,0,"When being logged out and using a link from Recentchanges like this:\n\nURL\n\nAnd then trying to log in, it will return to ""Main Page"".",OBSERVED BUG BEHAVIOR,, 15322,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter","When being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",1341777180,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4yxpk2dzj5i44ge226gc,task_description,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: http://commons.wikimedia.org/?diff=73980366&oldid=10204883&rcid=75133143 And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major","[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter./n/nWhen being logged out and using a link from Recentchanges like this: URL And then trying to log in, it will return to ""Main Page"". -------------------------- **Version**: 1.19 **Severity**: major",Needs Triage,90,1341777207,NA,resolved,TRUE,c2,1,TRUE,FALSE,-60,TRUE,"['[Regression] ""returnto"" from Login broken when used from a page without \'title\' parameter.', 'When being logged out and using a link from Recentchanges like this:\n\nURL\n\nAnd then trying to log in, it will return to ""Main Page"".', '--------------------------\n**Version**: 1.19\n**Severity**: major']",TRUE,0,--------------------------\n**Version**: 1.19\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 15323,"[Regression] ""returnto"" from Login broken when used from a page without 'title' parameter"," *** This bug has been marked as a duplicate of bug 36053 ***",1341777207,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4yxpk2dzj5i44ge226gc,task_subcomment," *** This bug has been marked as a duplicate of bug 36053 ***"," *** This bug has been marked as a duplicate of bug 36053 ***",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-60,TRUE,['\n\n*** This bug has been marked as a duplicate of bug 36053 ***'],NA,0,\n\n*** This bug has been marked as a duplicate of bug 36053 ***,ISSUE CONTENT MANAGEMENT,, 15335,Enable STARTTLS (both inbound and outbound) on lists,lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,1367525524,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-4j2dctchb5aolz7ppy73,task_description,Enable STARTTLS (both inbound and outbound) on lists./n/nlists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,Enable STARTTLS (both inbound and outbound) on lists./n/nlists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,High,80,1442835795,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c2,1,TRUE,FALSE,-17,TRUE,"['Enable STARTTLS (both inbound and outbound) on lists.', 'lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.']",FALSE,0,Enable STARTTLS (both inbound and outbound) on lists.,EXPECTED BEHAVIOR,, 15335,Enable STARTTLS (both inbound and outbound) on lists,lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,1367525524,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-4j2dctchb5aolz7ppy73,task_description,Enable STARTTLS (both inbound and outbound) on lists./n/nlists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,Enable STARTTLS (both inbound and outbound) on lists./n/nlists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,High,80,1442835795,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c2,1,TRUE,FALSE,-17,TRUE,"['Enable STARTTLS (both inbound and outbound) on lists.', 'lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.']",FALSE,0,lists should offer STARTTLS encryption on inbound mail and negotiate TLS on outbound mail as well.,EXPECTED BEHAVIOR,, 15336,Enable STARTTLS (both inbound and outbound) on lists,"Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[https://gerrit.wikimedia.org/r/231973]]",1443213401,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[https://gerrit.wikimedia.org/r/231973]]","Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,108,TRUE,"['Change 231973 abandoned by Ori.livneh:\nAdd simple haveged module; apply on fermium\n\nReason:\nNot needed.', '[[GERRIT_URL]]']",NA,0,Change 231973 abandoned by Ori.livneh:\nAdd simple haveged module; apply on fermium\n\nReason:\nNot needed.,TASK PROGRESS,, 15336,Enable STARTTLS (both inbound and outbound) on lists,"Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[https://gerrit.wikimedia.org/r/231973]]",1443213401,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[https://gerrit.wikimedia.org/r/231973]]","Change 231973 abandoned by Ori.livneh: Add simple haveged module; apply on fermium Reason: Not needed. [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,108,TRUE,"['Change 231973 abandoned by Ori.livneh:\nAdd simple haveged module; apply on fermium\n\nReason:\nNot needed.', '[[GERRIT_URL]]']",NA,0,[[GERRIT_URL]],NA,, 15337,Enable STARTTLS (both inbound and outbound) on lists,This should be done now.,1442835795,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,This should be done now.,This should be done now.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,107,TRUE,['This should be done now.'],NA,0,This should be done now.,TASK PROGRESS,, 15338,Enable STARTTLS (both inbound and outbound) on lists,"Change 239800 merged by Faidon Liambotis: mailman: enable TLS for lists.wikimedia.org [[https://gerrit.wikimedia.org/r/239800]]",1442830233,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Change 239800 merged by Faidon Liambotis: mailman: enable TLS for lists.wikimedia.org [[https://gerrit.wikimedia.org/r/239800]]","Change 239800 merged by Faidon Liambotis: mailman: enable TLS for lists.wikimedia.org [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,107,TRUE,['Change 239800 merged by Faidon Liambotis:\nmailman: enable TLS for lists.wikimedia.org\n\n[[GERRIT_URL]]'],NA,0,Change 239800 merged by Faidon Liambotis:\nmailman: enable TLS for lists.wikimedia.org\n\n[[GERRIT_URL]],TASK PROGRESS,, 15339,Enable STARTTLS (both inbound and outbound) on lists,"Change 239800 had a related patch set uploaded (by Faidon Liambotis): mailman: enable TLS for lists.wikimedia.org [[https://gerrit.wikimedia.org/r/239800]] ",1442830203,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Change 239800 had a related patch set uploaded (by Faidon Liambotis): mailman: enable TLS for lists.wikimedia.org [[https://gerrit.wikimedia.org/r/239800]] ","Change 239800 had a related patch set uploaded (by Faidon Liambotis): mailman: enable TLS for lists.wikimedia.org [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,107,TRUE,['Change 239800 had a related patch set uploaded (by Faidon Liambotis):\nmailman: enable TLS for lists.wikimedia.org\n\n[[GERRIT_URL]]'],NA,0,Change 239800 had a related patch set uploaded (by Faidon Liambotis):\nmailman: enable TLS for lists.wikimedia.org\n\n[[GERRIT_URL]],TASK PROGRESS,, 15340,Enable STARTTLS (both inbound and outbound) on lists,This is now unblocked since mailman has been migrated.,1442597317,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,This is now unblocked since mailman has been migrated.,This is now unblocked since mailman has been migrated.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,107,TRUE,['This is now unblocked since mailman has been migrated.'],NA,0,This is now unblocked since mailman has been migrated.,TASK PROGRESS,, 15341,Enable STARTTLS (both inbound and outbound) on lists,ticket is a duplicate of T101451,1438796890,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,ticket is a duplicate of T101451,ticket is a duplicate of T101451,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,101,TRUE,['ticket is a duplicate of T101451'],NA,0,ticket is a duplicate of T101451,ISSUE CONTENT MANAGEMENT,, 15342,Enable STARTTLS (both inbound and outbound) on lists,"Also this one. http://onerng.info/ Not yet shipping??",1432683502,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Also this one. http://onerng.info/ Not yet shipping??","Also this one. URL Not yet shipping??",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['Also this one.', 'URL\nNot yet shipping?', '?']",NA,0,Also this one.,SOCIAL CONVERSATION,, 15342,Enable STARTTLS (both inbound and outbound) on lists,"Also this one. http://onerng.info/ Not yet shipping??",1432683502,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Also this one. http://onerng.info/ Not yet shipping??","Also this one. URL Not yet shipping??",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['Also this one.', 'URL\nNot yet shipping?', '?']",NA,0,URL\nNot yet shipping?,SOLUTION DISCUSSION,, 15342,Enable STARTTLS (both inbound and outbound) on lists,"Also this one. http://onerng.info/ Not yet shipping??",1432683502,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"Also this one. http://onerng.info/ Not yet shipping??","Also this one. URL Not yet shipping??",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['Also this one.', 'URL\nNot yet shipping?', '?']",NA,0,?,NA,, 15343,Enable STARTTLS (both inbound and outbound) on lists,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",1432683149,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel","FWIW: Here are some HW random number generators that may help with the entropy needs. URL URL These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['FWIW: Here are some HW random number generators that may help with the entropy needs.', 'URL\nURL\n\nThese are both relatively inexpensive.', 'Would that help make this deployable?', 'Cheers,\n\nJoel']",NA,0,FWIW: Here are some HW random number generators that may help with the entropy needs.,INVESTIGATION AND EXPLORATION,, 15343,Enable STARTTLS (both inbound and outbound) on lists,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",1432683149,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel","FWIW: Here are some HW random number generators that may help with the entropy needs. URL URL These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['FWIW: Here are some HW random number generators that may help with the entropy needs.', 'URL\nURL\n\nThese are both relatively inexpensive.', 'Would that help make this deployable?', 'Cheers,\n\nJoel']",NA,0,URL\nURL\n\nThese are both relatively inexpensive.,SOLUTION DISCUSSION,, 15343,Enable STARTTLS (both inbound and outbound) on lists,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",1432683149,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel","FWIW: Here are some HW random number generators that may help with the entropy needs. URL URL These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['FWIW: Here are some HW random number generators that may help with the entropy needs.', 'URL\nURL\n\nThese are both relatively inexpensive.', 'Would that help make this deployable?', 'Cheers,\n\nJoel']",NA,0,Would that help make this deployable?,INVESTIGATION AND EXPLORATION,, 15343,Enable STARTTLS (both inbound and outbound) on lists,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",1432683149,PHID-USER-siktv47fljwejss47lay,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"FWIW: Here are some HW random number generators that may help with the entropy needs. http://www.araneus.fi/products/alea2/en/ https://www.tindie.com/products/WaywardGeek/infinite-noise/ These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel","FWIW: Here are some HW random number generators that may help with the entropy needs. URL URL These are both relatively inexpensive. Would that help make this deployable? Cheers, Joel",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,"['FWIW: Here are some HW random number generators that may help with the entropy needs.', 'URL\nURL\n\nThese are both relatively inexpensive.', 'Would that help make this deployable?', 'Cheers,\n\nJoel']",NA,0,"Cheers,\n\nJoel",SOCIAL CONVERSATION,, 15344,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Tue Sep 16 11:22:04 2014, fgiunchedi wrote:%%% > On Wed Dec 11 11:03:30 2013, mark wrote: > > > > On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests- > > <comment at wikimedia> > > re: entropy if that turns out to be still a problem we can use > something like > haveged",1410868193,PHID-USER-wr3pospifdaxghmtobvr,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Tue Sep 16 11:22:04 2014, fgiunchedi wrote:%%% > On Wed Dec 11 11:03:30 2013, mark wrote: > > > > On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests- > > <comment at wikimedia> > > re: entropy if that turns out to be still a problem we can use > something like > haveged","%%%On Tue Sep 16 11:22:04 2014, fgiunchedi wrote:%%% QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,54,TRUE,"['%%%On Tue Sep 16 11:22:04 2014, fgiunchedi wrote:%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE']",NA,0,"%%%On Tue Sep 16 11:22:04 2014, fgiunchedi wrote:%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE",SOCIAL CONVERSATION,, 15345,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Wed Dec 11 11:03:30 2013, mark wrote:%%% > > On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests- > <comment at wikimedia> we had this enabled once upon a time, but the list server kept > running out of random entropy. Since it wasn't all that useful and I > had no time to deal with it, I just disabled it at the time. > > I'm not at all against having this reenabled, just be aware that this > can be an issue. %%%FWIW I think that despite no cert validation we still want to encrypt smtp%%% %%%traffic (we could audit certificate fingerprints, if anything)%%% %%%re: entropy if that turns out to be still a problem we can use something like%%% %%%haveged%%%",1410866524,PHID-USER-wr3pospifdaxghmtobvr,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Wed Dec 11 11:03:30 2013, mark wrote:%%% > > On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests- > <comment at wikimedia> we had this enabled once upon a time, but the list server kept > running out of random entropy. Since it wasn't all that useful and I > had no time to deal with it, I just disabled it at the time. > > I'm not at all against having this reenabled, just be aware that this > can be an issue. %%%FWIW I think that despite no cert validation we still want to encrypt smtp%%% %%%traffic (we could audit certificate fingerprints, if anything)%%% %%%re: entropy if that turns out to be still a problem we can use something like%%% %%%haveged%%%","%%%On Wed Dec 11 11:03:30 2013, mark wrote:%%% QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE %%%FWIW I think that despite no cert validation we still want to encrypt smtp%%% %%%traffic (we could audit certificate fingerprints, if anything)%%% %%%re: entropy if that turns out to be still a problem we can use something like%%% %%%haveged%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,54,TRUE,"['%%%On Wed Dec 11 11:03:30 2013, mark wrote:%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n%%%FWIW I think that despite no cert validation we still want to encrypt smtp%%%\n%%%traffic (we could audit certificate fingerprints, if anything)%%%\n%%%re: entropy if that turns out to be still a problem we can use something like%%%\n%%%haveged%%%']",NA,0,"%%%On Wed Dec 11 11:03:30 2013, mark wrote:%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n%%%FWIW I think that despite no cert validation we still want to encrypt smtp%%%\n%%%traffic (we could audit certificate fingerprints, if anything)%%%\n%%%re: entropy if that turns out to be still a problem we can use something like%%%\n%%%haveged%%%",SOLUTION DISCUSSION,, 15346,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",1386759810,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%","%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,15,TRUE,"['%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy.', ""Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%%\n%%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%""]",NA,0,"%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy.",SOLUTION DISCUSSION,, 15346,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",1386759810,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%","%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy. Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%% %%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,15,TRUE,"['%%%On Nov 21, 2013, at 5:52 AM, Faidon Liambotis via RT <ops-requests-comment at wikimedia> we had this enabled once upon a time, but the list server kept running out of random entropy.', ""Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%%\n%%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%""]",NA,0,"Since it wasn't all that useful and I had no time to deal with it, I just disabled it at the time.%%%\n%%%I'm not at all against having this reenabled, just be aware that this can be an issue.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%",SOLUTION DISCUSSION,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,"Noone%%%\n%%%checks for certificate signatures and rejects, ever.",SOLUTION USAGE,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,There is no known%%%\n%%%equivalent to browser CAs for mail certificates.,INVESTIGATION AND EXPLORATION,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.,POTENTIAL NEW ISSUES AND REQUESTS,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable.",FUTURE PLANS,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,"At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix.",SOCIAL CONVERSATION,, 15347,Enable STARTTLS (both inbound and outbound) on lists,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",1385009538,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% >Any chance we could consider this as part of the mail migration? %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%","%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%% QUOTE %%%Yup, it's already in the TODO.%%% %%%Note that the actual security benefit of this is very disputable. Noone%%% %%%checks for certificate signatures and rejects, ever. There is no known%%% %%%equivalent to browser CAs for mail certificates. At Debian we even do%%% %%%DANE, noone checks that either :)%%% %%%I assume this came from EFF's matrix. They know that noone does%%% %%%validation as well and are discussing ways to fix this. I'm not very%%% %%%optimistic.%%% %%%Regards,%%% %%%Faidon%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"[""%%%On Thu, Nov 21, 2013 at 04:45:45AM +0000, Ken Snider via RT wrote:%%%\nQUOTE\n%%%Yup, it's already in the TODO.%%%\n%%%Note that the actual security benefit of this is very disputable."", 'Noone%%%\n%%%checks for certificate signatures and rejects, ever.', 'There is no known%%%\n%%%equivalent to browser CAs for mail certificates.', ""At Debian we even do%%%\n%%%DANE, noone checks that either :)%%%\n%%%I assume this came from EFF's matrix."", 'They know that noone does%%%\n%%%validation as well and are discussing ways to fix this.', ""I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%""]",NA,0,"I'm not very%%%\n%%%optimistic.%%%\n%%%Regards,%%%\n%%%Faidon%%%",SOCIAL CONVERSATION,, 15348,Enable STARTTLS (both inbound and outbound) on lists,"`ksnider wrote:` %%%Mark / Faidon,%%% %%%Any chance we could consider this as part of the mail migration?%%% %%%Thanks.%%% %%%--Ken.%%%",1385009145,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"`ksnider wrote:` %%%Mark / Faidon,%%% %%%Any chance we could consider this as part of the mail migration?%%% %%%Thanks.%%% %%%--Ken.%%%","CODE %%%Mark / Faidon,%%% %%%Any chance we could consider this as part of the mail migration?%%% %%%Thanks.%%% %%%--Ken.%%%",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,12,TRUE,"['CODE\n\n%%%Mark / Faidon,%%%\n%%%Any chance we could consider this as part of the mail migration?%%%\n%%%Thanks.%%%\n%%%--Ken.%%%']",NA,0,"CODE\n\n%%%Mark / Faidon,%%%\n%%%Any chance we could consider this as part of the mail migration?%%%\n%%%Thanks.%%%\n%%%--Ken.%%%",ISSUE CONTENT MANAGEMENT,, 15349,Enable STARTTLS (both inbound and outbound) on lists,"`<mdennis at wikimedia> wrote:` %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% > This already was in RT via dzahn via postmaster@. (same user reported > it) Merging. > %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%",1368467479,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"`<mdennis at wikimedia> wrote:` %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% > This already was in RT via dzahn via postmaster@. (same user reported > it) Merging. > %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%","CODE %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% QUOTE QUOTE QUOTE %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['CODE\n\n%%%Thank you both.', "":)%%%\n%%%I'll let the correspondent know that it's being looked at.%%%\n%%%Maggie%%%\n%%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%%\n%%%<ops-requests at wikimedia> wrote:%%%\nQUOTE\nQUOTE\nQUOTE\n%%%--%%%\n%%%Maggie Dennis%%%\n%%%Senior Community Advocate%%%\n%%%Wikimedia Foundation, Inc.%%%""]",NA,0,CODE\n\n%%%Thank you both.,SOCIAL CONVERSATION,, 15349,Enable STARTTLS (both inbound and outbound) on lists,"`<mdennis at wikimedia> wrote:` %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% > This already was in RT via dzahn via postmaster@. (same user reported > it) Merging. > %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%",1368467479,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"`<mdennis at wikimedia> wrote:` %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% > This already was in RT via dzahn via postmaster@. (same user reported > it) Merging. > %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%","CODE %%%Thank you both. :)%%% %%%I'll let the correspondent know that it's being looked at.%%% %%%Maggie%%% %%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%% %%%<ops-requests at wikimedia> wrote:%%% QUOTE QUOTE QUOTE %%%--%%% %%%Maggie Dennis%%% %%%Senior Community Advocate%%% %%%Wikimedia Foundation, Inc.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['CODE\n\n%%%Thank you both.', "":)%%%\n%%%I'll let the correspondent know that it's being looked at.%%%\n%%%Maggie%%%\n%%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%%\n%%%<ops-requests at wikimedia> wrote:%%%\nQUOTE\nQUOTE\nQUOTE\n%%%--%%%\n%%%Maggie Dennis%%%\n%%%Senior Community Advocate%%%\n%%%Wikimedia Foundation, Inc.%%%""]",NA,0,":)%%%\n%%%I'll let the correspondent know that it's being looked at.%%%\n%%%Maggie%%%\n%%%On Sun, May 12, 2013 at 9:50 AM, Jeremy Baron via RT <%%%\n%%%<ops-requests at wikimedia> wrote:%%%\nQUOTE\nQUOTE\nQUOTE\n%%%--%%%\n%%%Maggie Dennis%%%\n%%%Senior Community Advocate%%%\n%%%Wikimedia Foundation, Inc.%%%",CONTRIBUTION AND COMMITMENT,, 15350,Enable STARTTLS (both inbound and outbound) on lists,Merged into ticket #5075 by jeremyb,1368366685,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,Merged into ticket #5075 by jeremyb,Merged into ticket #5075 by jeremyb,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,['Merged into ticket #5075 by jeremyb'],NA,0,Merged into ticket #5075 by jeremyb,ACTION ON ISSUE,, 15351,Enable STARTTLS (both inbound and outbound) on lists,//Status changed from 'new' to 'open' by RT_System//,1368366659,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//Status changed from 'new' to 'open' by RT_System//,//Status changed from 'new' to 'open' by RT_System//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"[""//Status changed from 'new' to 'open' by RT_System//""]",NA,0,//Status changed from 'new' to 'open' by RT_System//,ACTION ON ISSUE ,, 15352,Enable STARTTLS (both inbound and outbound) on lists,"%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%",1368366658,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%","%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['%%%This already was in RT via dzahn via postmaster@.', '(same user reported%%%\n%%%it) Merging.%%%']",NA,0,%%%This already was in RT via dzahn via postmaster@.,ISSUE CONTENT MANAGEMENT,, 15352,Enable STARTTLS (both inbound and outbound) on lists,"%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%",1368366658,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%","%%%This already was in RT via dzahn via postmaster@. (same user reported%%% %%%it) Merging.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['%%%This already was in RT via dzahn via postmaster@.', '(same user reported%%%\n%%%it) Merging.%%%']",NA,0,(same user reported%%%\n%%%it) Merging.%%%,TASK PROGRESS,, 15353,Enable STARTTLS (both inbound and outbound) on lists,"`wooster wrote:` %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% > Hello, CT. :) > > I'm told that I should send this to you - can you help this gentleman or > tell me to whom I should refer him instead? > > Maggie > > ---------- Forwarded message ---------- > From: Rich Wales <richw at richw> > To: <answers at wikimedia> > > > Hi. I sent a message about the following issue to * > <postmaster at wikimedia> (Postfix) with ESMTP id A4BE717403E0 > for <richw at richw> <richw at richw>; Thu, 2 May 2013 11:53:45 -0700 (PDT) > > It also appears that *lists.wikimedia.org* does not offer STARTTLS to > SMTP clients. I tried connecting to it just now, and here is what I saw; > note that the list of capabilities in the EHLO response does not mention > STARTTLS: > > 220 sodium.wikimedia.org ESMTP Exim 4.71 Thu, 02 May 2013 19:04:00 +0000 > ehlo pigeon.richw.org > 250-sodium.wikimedia.org Hello whodunit.stanford.edu [68.65.164.12] > 250-SIZE 52428800 > 250-PIPELINING > 250 HELP > quit > 221 sodium.wikimedia.org closing connection > > I realize you can't fully control the security of other hosts which send > mail to, or receive mail from, your server. However, it seems to me that > enabling STARTTLS on *lists.wikimedia.org* (both in its SMTP server and > its SMTP client code) would be a step in the right direction. > > Any thoughts on this? > ~~ > *Rich Wales* (Richwales <http://en.wikipedia.org/wiki/User:Richwales>) *-- > no relation to Jimbo* > >",1368223415,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"`wooster wrote:` %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% > Hello, CT. :) > > I'm told that I should send this to you - can you help this gentleman or > tell me to whom I should refer him instead? > > Maggie > > ---------- Forwarded message ---------- > From: Rich Wales <richw at richw> > To: <answers at wikimedia> > > > Hi. I sent a message about the following issue to * > <postmaster at wikimedia> (Postfix) with ESMTP id A4BE717403E0 > for <richw at richw> <richw at richw>; Thu, 2 May 2013 11:53:45 -0700 (PDT) > > It also appears that *lists.wikimedia.org* does not offer STARTTLS to > SMTP clients. I tried connecting to it just now, and here is what I saw; > note that the list of capabilities in the EHLO response does not mention > STARTTLS: > > 220 sodium.wikimedia.org ESMTP Exim 4.71 Thu, 02 May 2013 19:04:00 +0000 > ehlo pigeon.richw.org > 250-sodium.wikimedia.org Hello whodunit.stanford.edu [68.65.164.12] > 250-SIZE 52428800 > 250-PIPELINING > 250 HELP > quit > 221 sodium.wikimedia.org closing connection > > I realize you can't fully control the security of other hosts which send > mail to, or receive mail from, your server. However, it seems to me that > enabling STARTTLS on *lists.wikimedia.org* (both in its SMTP server and > its SMTP client code) would be a step in the right direction. > > Any thoughts on this? > ~~ > *Rich Wales* (Richwales <http://en.wikipedia.org/wiki/User:Richwales>) *-- > no relation to Jimbo* > >","CODE %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% 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",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['CODE\n\n%%%Hi Maggie,%%%\n%%%I will get the discussion going on this with the team.', ""It is a 'nice to%%%\n%%%have' feature to enable (IMHO) and would need some work on our side.%%%\n%%%Thanks,%%%\n%%%CT%%%\n%%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%%\n%%%<answers at wikimedia>%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE""]",NA,0,"CODE\n\n%%%Hi Maggie,%%%\n%%%I will get the discussion going on this with the team.",CONTRIBUTION AND COMMITMENT,, 15353,Enable STARTTLS (both inbound and outbound) on lists,"`wooster wrote:` %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% > Hello, CT. :) > > I'm told that I should send this to you - can you help this gentleman or > tell me to whom I should refer him instead? > > Maggie > > ---------- Forwarded message ---------- > From: Rich Wales <richw at richw> > To: <answers at wikimedia> > > > Hi. I sent a message about the following issue to * > <postmaster at wikimedia> (Postfix) with ESMTP id A4BE717403E0 > for <richw at richw> <richw at richw>; Thu, 2 May 2013 11:53:45 -0700 (PDT) > > It also appears that *lists.wikimedia.org* does not offer STARTTLS to > SMTP clients. I tried connecting to it just now, and here is what I saw; > note that the list of capabilities in the EHLO response does not mention > STARTTLS: > > 220 sodium.wikimedia.org ESMTP Exim 4.71 Thu, 02 May 2013 19:04:00 +0000 > ehlo pigeon.richw.org > 250-sodium.wikimedia.org Hello whodunit.stanford.edu [68.65.164.12] > 250-SIZE 52428800 > 250-PIPELINING > 250 HELP > quit > 221 sodium.wikimedia.org closing connection > > I realize you can't fully control the security of other hosts which send > mail to, or receive mail from, your server. However, it seems to me that > enabling STARTTLS on *lists.wikimedia.org* (both in its SMTP server and > its SMTP client code) would be a step in the right direction. > > Any thoughts on this? > ~~ > *Rich Wales* (Richwales <http://en.wikipedia.org/wiki/User:Richwales>) *-- > no relation to Jimbo* > >",1368223415,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"`wooster wrote:` %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% > Hello, CT. :) > > I'm told that I should send this to you - can you help this gentleman or > tell me to whom I should refer him instead? > > Maggie > > ---------- Forwarded message ---------- > From: Rich Wales <richw at richw> > To: <answers at wikimedia> > > > Hi. I sent a message about the following issue to * > <postmaster at wikimedia> (Postfix) with ESMTP id A4BE717403E0 > for <richw at richw> <richw at richw>; Thu, 2 May 2013 11:53:45 -0700 (PDT) > > It also appears that *lists.wikimedia.org* does not offer STARTTLS to > SMTP clients. I tried connecting to it just now, and here is what I saw; > note that the list of capabilities in the EHLO response does not mention > STARTTLS: > > 220 sodium.wikimedia.org ESMTP Exim 4.71 Thu, 02 May 2013 19:04:00 +0000 > ehlo pigeon.richw.org > 250-sodium.wikimedia.org Hello whodunit.stanford.edu [68.65.164.12] > 250-SIZE 52428800 > 250-PIPELINING > 250 HELP > quit > 221 sodium.wikimedia.org closing connection > > I realize you can't fully control the security of other hosts which send > mail to, or receive mail from, your server. However, it seems to me that > enabling STARTTLS on *lists.wikimedia.org* (both in its SMTP server and > its SMTP client code) would be a step in the right direction. > > Any thoughts on this? > ~~ > *Rich Wales* (Richwales <http://en.wikipedia.org/wiki/User:Richwales>) *-- > no relation to Jimbo* > >","CODE %%%Hi Maggie,%%% %%%I will get the discussion going on this with the team. It is a 'nice to%%% %%%have' feature to enable (IMHO) and would need some work on our side.%%% %%%Thanks,%%% %%%CT%%% %%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%% %%%<answers at wikimedia>%%% 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",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['CODE\n\n%%%Hi Maggie,%%%\n%%%I will get the discussion going on this with the team.', ""It is a 'nice to%%%\n%%%have' feature to enable (IMHO) and would need some work on our side.%%%\n%%%Thanks,%%%\n%%%CT%%%\n%%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%%\n%%%<answers at wikimedia>%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE""]",NA,0,"It is a 'nice to%%%\n%%%have' feature to enable (IMHO) and would need some work on our side.%%%\n%%%Thanks,%%%\n%%%CT%%%\n%%%On Fri, May 10, 2013 at 10:19 AM, Wikimedia Answers%%%\n%%%<answers at wikimedia>%%%\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE",POTENTIAL NEW ISSUES AND REQUESTS,, 15354,Enable STARTTLS (both inbound and outbound) on lists,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",1367835548,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%","%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%The problem in the past was that this would use up (starve) all random entropy%%%\n%%%because of the many deliveries, and then block.', 'But with newer hardware and%%%\n%%%potentially hw RNGs, the situation may be better now.', 'We can test it again.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%']",NA,0,"%%%The problem in the past was that this would use up (starve) all random entropy%%%\n%%%because of the many deliveries, and then block.",SOLUTION DISCUSSION,, 15354,Enable STARTTLS (both inbound and outbound) on lists,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",1367835548,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%","%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%The problem in the past was that this would use up (starve) all random entropy%%%\n%%%because of the many deliveries, and then block.', 'But with newer hardware and%%%\n%%%potentially hw RNGs, the situation may be better now.', 'We can test it again.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%']",NA,0,"But with newer hardware and%%%\n%%%potentially hw RNGs, the situation may be better now.",SOLUTION DISCUSSION,, 15354,Enable STARTTLS (both inbound and outbound) on lists,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",1367835548,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%","%%%The problem in the past was that this would use up (starve) all random entropy%%% %%%because of the many deliveries, and then block. But with newer hardware and%%% %%%potentially hw RNGs, the situation may be better now. We can test it again.%%% %%%--%%% %%%Mark Bergsma <mark at wikimedia>%%% %%%Lead Operations Architect%%% %%%Wikimedia Foundation%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%The problem in the past was that this would use up (starve) all random entropy%%%\n%%%because of the many deliveries, and then block.', 'But with newer hardware and%%%\n%%%potentially hw RNGs, the situation may be better now.', 'We can test it again.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%']",NA,0,We can test it again.%%%\n%%%--%%%\n%%%Mark Bergsma <mark at wikimedia>%%%\n%%%Lead Operations Architect%%%\n%%%Wikimedia Foundation%%%,TESTING,, 15355,Enable STARTTLS (both inbound and outbound) on lists,Issue taken by **mark**,1367835485,PHID-USER-hovi6c77qompv5qd7gtz,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,Issue taken by **mark**,Issue taken by **mark**,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['Issue taken by **mark**'],NA,0,Issue taken by **mark**,ACTION ON ISSUE,, 15356,Enable STARTTLS (both inbound and outbound) on lists,//Subject changed from 'Fwd: Potential security issue with mail from lists.wikimedia.org' to 'enable STARTTLS (both inbound and outbound) on sodium MTA' by jeremyb//,1367554439,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//Subject changed from 'Fwd: Potential security issue with mail from lists.wikimedia.org' to 'enable STARTTLS (both inbound and outbound) on sodium MTA' by jeremyb//,//Subject changed from 'Fwd: Potential security issue with mail from lists.wikimedia.org' to 'enable STARTTLS (both inbound and outbound) on sodium MTA' by jeremyb//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"[""//Subject changed from 'Fwd: Potential security issue with mail from lists.wikimedia.org' to 'enable STARTTLS (both inbound and outbound) on sodium MTA' by jeremyb//""]",NA,0,//Subject changed from 'Fwd: Potential security issue with mail from lists.wikimedia.org' to 'enable STARTTLS (both inbound and outbound) on sodium MTA' by jeremyb//,ACTION ON ISSUE,, 15357,Enable STARTTLS (both inbound and outbound) on lists,//Status changed from 'new' to 'open' by RT_System//,1367554439,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//Status changed from 'new' to 'open' by RT_System//,//Status changed from 'new' to 'open' by RT_System//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"[""//Status changed from 'new' to 'open' by RT_System//""]",NA,0,//Status changed from 'new' to 'open' by RT_System//,ACTION ON ISSUE,, 15358,Enable STARTTLS (both inbound and outbound) on lists,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%",1367554439,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%","%%%Add mark to CC. Should also test mchenry, etc. too.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%Add mark to CC.', 'Should also test mchenry, etc.', 'too.%%%']",NA,0,%%%Add mark to CC.,ACTION ON ISSUE ,, 15358,Enable STARTTLS (both inbound and outbound) on lists,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%",1367554439,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%","%%%Add mark to CC. Should also test mchenry, etc. too.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%Add mark to CC.', 'Should also test mchenry, etc.', 'too.%%%']",NA,0,"Should also test mchenry, etc.",TESTING,, 15358,Enable STARTTLS (both inbound and outbound) on lists,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%",1367554439,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,"%%%Add mark to CC. Should also test mchenry, etc. too.%%%","%%%Add mark to CC. Should also test mchenry, etc. too.%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['%%%Add mark to CC.', 'Should also test mchenry, etc.', 'too.%%%']",NA,0,too.%%%,NA,, 15359,Enable STARTTLS (both inbound and outbound) on lists,//Cc mark added by jeremyb//,1367554310,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//Cc mark added by jeremyb//,//Cc mark added by jeremyb//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['//Cc mark added by jeremyb//'],NA,0,//Cc mark added by jeremyb//,ACTION ON ISSUE,, 15360,Enable STARTTLS (both inbound and outbound) on lists,//AdminCc jeremyb added by jeremyb//,1367537564,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//AdminCc jeremyb added by jeremyb//,//AdminCc jeremyb added by jeremyb//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['//AdminCc jeremyb added by jeremyb//'],NA,0,//AdminCc jeremyb added by jeremyb//,ACTION ON ISSUE,, 15361,Enable STARTTLS (both inbound and outbound) on lists,//AdminCc thehelpfulone added by thehelpfulone//,1367534821,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-4j2dctchb5aolz7ppy73,task_subcomment,//AdminCc thehelpfulone added by thehelpfulone//,//AdminCc thehelpfulone added by thehelpfulone//,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['//AdminCc thehelpfulone added by thehelpfulone//'],NA,0,//AdminCc thehelpfulone added by thehelpfulone//,ACTION ON ISSUE ,, 15370,[Bug] Login issue with add language links widget,"> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links) **See Also**: {T68521}",1368390120,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_description,"[Bug] Login issue with add language links widget./n/n> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links) **See Also**: {T68521}","[Bug] Login issue with add language links widget./n/n> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at URL **See Also**: {T68521}",High,80,1443601911,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c2,1,TRUE,FALSE,-16,TRUE,"['[Bug] Login issue with add language links widget.', 'QUOTE\n\n(Reported at URL\n\n**See Also**:\n{T68521}']",FALSE,0,[Bug] Login issue with add language links widget.,OBSERVED BUG BEHAVIOR,, 15370,[Bug] Login issue with add language links widget,"> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links) **See Also**: {T68521}",1368390120,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_description,"[Bug] Login issue with add language links widget./n/n> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#.22You_need_to_be_logged_in.22_error_when_trying_to_add_interwiki_links) **See Also**: {T68521}","[Bug] Login issue with add language links widget./n/n> ""Whenever I try to add an interwiki link by following the ""Add link"" link in the ""Languages"" section, the following error message pops up: ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature."" However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the ""central data repository"" is or how to log in there. <20><><EFBFBD>Psychonaut (talk) 17:43, 11 May 2013 (UTC)"" (Reported at URL **See Also**: {T68521}",High,80,1443601911,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c2,1,TRUE,FALSE,-16,TRUE,"['[Bug] Login issue with add language links widget.', 'QUOTE\n\n(Reported at URL\n\n**See Also**:\n{T68521}']",FALSE,0,QUOTE\n\n(Reported at URL\n\n**See Also**:\n{T68521},OBSERVED BUG BEHAVIOR,, 15371,[Bug] Login issue with add language links widget,"Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.",1443601998,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.","Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,109,TRUE,"[""Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.""]",NA,0,"Given this didn't make it into the branch this week, this is probably not going to be deployed to the Wikipedias before October 15.",FUTURE PLANS,, 15372,[Bug] Login issue with add language links widget,"Change 238469 merged by jenkins-bot: Use mw.ForeignApi in getLocationAgnosticMwApi [[https://gerrit.wikimedia.org/r/238469]]",1443601890,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Change 238469 merged by jenkins-bot: Use mw.ForeignApi in getLocationAgnosticMwApi [[https://gerrit.wikimedia.org/r/238469]]","Change 238469 merged by jenkins-bot: Use mw.ForeignApi in getLocationAgnosticMwApi [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,109,TRUE,['Change 238469 merged by jenkins-bot:\nUse mw.ForeignApi in getLocationAgnosticMwApi\n\n[[GERRIT_URL]]'],NA,0,Change 238469 merged by jenkins-bot:\nUse mw.ForeignApi in getLocationAgnosticMwApi\n\n[[GERRIT_URL]],TASK PROGRESS,, 15373,[Bug] Login issue with add language links widget,"Change 238469 had a related patch set uploaded (by Hoo man): Use mw.ForeignApi in getLocationAgnosticMwApi [[https://gerrit.wikimedia.org/r/238469]] ",1442332619,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Change 238469 had a related patch set uploaded (by Hoo man): Use mw.ForeignApi in getLocationAgnosticMwApi [[https://gerrit.wikimedia.org/r/238469]] ","Change 238469 had a related patch set uploaded (by Hoo man): Use mw.ForeignApi in getLocationAgnosticMwApi [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,106,TRUE,['Change 238469 had a related patch set uploaded (by Hoo man):\nUse mw.ForeignApi in getLocationAgnosticMwApi\n\n[[GERRIT_URL]]'],NA,0,Change 238469 had a related patch set uploaded (by Hoo man):\nUse mw.ForeignApi in getLocationAgnosticMwApi\n\n[[GERRIT_URL]],TASK PROGRESS,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,"QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.",OBSERVED BUG BEHAVIOR,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,Then I go back within the same tab(!),OBSERVED BUG BEHAVIOR,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,"in Firefox, and reload it.",BUG REPRODUCTION,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,Maybe that helps?,SOCIAL CONVERSATION,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,Greetimgs\nhdamm,SOCIAL CONVERSATION,, 15374,[Bug] Login issue with add language links widget,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",1441530863,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#1612338, @Hdamm wrote: > I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). > What can I do? > Greetings > hdamm BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm","QUOTE QUOTE QUOTE QUOTE QUOTE BTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message. Then I go back within the same tab(!) in Firefox, and reload it. That's when I get the same error message, again. Maybe that helps? Greetimgs hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBTW - when I get that error message, I click on the link to log in to WikiData, where I get the ""Welcome to Wikidata"" message.', 'Then I go back within the same tab(!)', 'in Firefox, and reload it.', ""That's when I get the same error message, again."", 'Maybe that helps?', 'Greetimgs\nhdamm']",NA,0,"That's when I get the same error message, again.",OBSERVED BUG BEHAVIOR,, 15375,[Bug] Login issue with add language links widget,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",1441530107,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm","I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"[""I'm getting this problem, too - since a couple of days?"", ""I'm also using Firefox (latest version)."", 'What can I do?', 'Greetings\nhdamm']",NA,0,What can I do?,INVESTIGATION AND EXPLORATION,, 15375,[Bug] Login issue with add language links widget,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",1441530107,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm","I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"[""I'm getting this problem, too - since a couple of days?"", ""I'm also using Firefox (latest version)."", 'What can I do?', 'Greetings\nhdamm']",NA,0,Greetings\nhdamm,SOCIAL CONVERSATION,, 15375,[Bug] Login issue with add language links widget,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",1441530107,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm","I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"[""I'm getting this problem, too - since a couple of days?"", ""I'm also using Firefox (latest version)."", 'What can I do?', 'Greetings\nhdamm']",NA,0,"I'm getting this problem, too - since a couple of days?",BUG REPRODUCTION,, 15375,[Bug] Login issue with add language links widget,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",1441530107,PHID-USER-nfhf74f5bmvkv57czxli,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm","I'm getting this problem, too - since a couple of days? I'm also using Firefox (latest version). What can I do? Greetings hdamm",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,105,TRUE,"[""I'm getting this problem, too - since a couple of days?"", ""I'm also using Firefox (latest version)."", 'What can I do?', 'Greetings\nhdamm']",NA,0,I'm also using Firefox (latest version).,BUG REPRODUCTION,, 15376,[Bug] Login issue with add language links widget,"Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",1440874632,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.","Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,104,TRUE,"[""Yeah, this should be easy to fix now for someone who knows Wikibase's code."", ""I tried, but I couldn't find where the Wikibase API code comes from.""]",NA,0,"Yeah, this should be easy to fix now for someone who knows Wikibase's code.",SOLUTION DISCUSSION,, 15376,[Bug] Login issue with add language links widget,"Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",1440874632,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.","Yeah, this should be easy to fix now for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,104,TRUE,"[""Yeah, this should be easy to fix now for someone who knows Wikibase's code."", ""I tried, but I couldn't find where the Wikibase API code comes from.""]",NA,0,"I tried, but I couldn't find where the Wikibase API code comes from.",CONTRIBUTION AND COMMITMENT,, 15377,[Bug] Login issue with add language links widget,"Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",1440874622,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.","Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,104,TRUE,"[""Yeah, this should be easy to fix for someone who knows Wikibase's code."", ""I tried, but I couldn't find where the Wikibase API code comes from.""]",NA,0,"Yeah, this should be easy to fix for someone who knows Wikibase's code.",SOLUTION DISCUSSION,, 15377,[Bug] Login issue with add language links widget,"Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",1440874622,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.","Yeah, this should be easy to fix for someone who knows Wikibase's code. I tried, but I couldn't find where the Wikibase API code comes from.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,104,TRUE,"[""Yeah, this should be easy to fix for someone who knows Wikibase's code."", ""I tried, but I couldn't find where the Wikibase API code comes from.""]",NA,0,"I tried, but I couldn't find where the Wikibase API code comes from.",CONTRIBUTION AND COMMITMENT,, 15378,[Bug] Login issue with add language links widget,"AIUI, {T66636} will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.",1439600095,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"AIUI, {T66636} will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.","AIUI, {T66636} will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,102,TRUE,"['AIUI, {T66636} will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.']",NA,0,"AIUI, {T66636} will allow Wikibase to use centralauthtoken without depending upon CentralAuth explicitly (core takes care of the dependency internally) and centralauthtoken should bypass any cookie issues.",SOLUTION DISCUSSION,, 15379,[Bug] Login issue with add language links widget,Another occurrence was brought up in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=675868961#InterWiki,1439461644,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,Another occurrence was brought up in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=675868961#InterWiki,Another occurrence was brought up in URL,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,102,TRUE,['Another occurrence was brought up in URL'],NA,0,Another occurrence was brought up in URL,BUG REPRODUCTION,, 15380,[Bug] Login issue with add language links widget,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",1436487973,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ","SCREEN_NAME or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,97,TRUE,"['SCREEN_NAME or anyone else who might know: Is this going to be fixed?', ""It can't be SUL problems, because SUL finalization is done."", ""It can't be HTTP vs HTTPS, because everything is forced to HTTPS."", 'If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).', 'In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.']",NA,0,SCREEN_NAME or anyone else who might know: Is this going to be fixed?,TASK PROGRESS,, 15380,[Bug] Login issue with add language links widget,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",1436487973,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ","SCREEN_NAME or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,97,TRUE,"['SCREEN_NAME or anyone else who might know: Is this going to be fixed?', ""It can't be SUL problems, because SUL finalization is done."", ""It can't be HTTP vs HTTPS, because everything is forced to HTTPS."", 'If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).', 'In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.']",NA,0,"If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).",SOLUTION DISCUSSION,, 15380,[Bug] Login issue with add language links widget,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",1436487973,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ","SCREEN_NAME or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,97,TRUE,"['SCREEN_NAME or anyone else who might know: Is this going to be fixed?', ""It can't be SUL problems, because SUL finalization is done."", ""It can't be HTTP vs HTTPS, because everything is forced to HTTPS."", 'If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).', 'In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.']",NA,0,"In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.",POTENTIAL NEW ISSUES AND REQUESTS,, 15380,[Bug] Login issue with add language links widget,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",1436487973,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ","SCREEN_NAME or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,97,TRUE,"['SCREEN_NAME or anyone else who might know: Is this going to be fixed?', ""It can't be SUL problems, because SUL finalization is done."", ""It can't be HTTP vs HTTPS, because everything is forced to HTTPS."", 'If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).', 'In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.']",NA,0,"It can't be SUL problems, because SUL finalization is done.",INVESTIGATION AND EXPLORATION,, 15380,[Bug] Login issue with add language links widget,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",1436487973,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"@Lydia_Pintscher or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ","SCREEN_NAME or anyone else who might know: Is this going to be fixed? It can't be SUL problems, because SUL finalization is done. It can't be HTTP vs HTTPS, because everything is forced to HTTPS. If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies). In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,97,TRUE,"['SCREEN_NAME or anyone else who might know: Is this going to be fixed?', ""It can't be SUL problems, because SUL finalization is done."", ""It can't be HTTP vs HTTPS, because everything is forced to HTTPS."", 'If the problem is not accepting third-party cookies, then the message needs to say that (or the software needs to be changed to not need cookies).', 'In the meantime, maybe someone would like to add [[w:ht:Lafy<66><79>v j<><6A>n]] to the list of articles about yellow fever.']",NA,0,"It can't be HTTP vs HTTPS, because everything is forced to HTTPS.",SOLUTION DISCUSSION,, 15381,[Bug] Login issue with add language links widget,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",1422231108,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ","I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,73,TRUE,"[""I'm getting this problem, too."", ""I'm also using Firefox (latest version) with third-party cookies disabled."", 'It might be nice to have a help page about this somewhere on Wikidata.']",NA,0,It might be nice to have a help page about this somewhere on Wikidata.,POTENTIAL NEW ISSUES AND REQUESTS,, 15381,[Bug] Login issue with add language links widget,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",1422231108,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ","I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,73,TRUE,"[""I'm getting this problem, too."", ""I'm also using Firefox (latest version) with third-party cookies disabled."", 'It might be nice to have a help page about this somewhere on Wikidata.']",NA,0,"I'm getting this problem, too.",BUG REPRODUCTION,, 15381,[Bug] Login issue with add language links widget,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",1422231108,PHID-USER-uf3buojo4ceizjywvyn5,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ","I'm getting this problem, too. I'm also using Firefox (latest version) with third-party cookies disabled. It might be nice to have a help page about this somewhere on Wikidata. ",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,73,TRUE,"[""I'm getting this problem, too."", ""I'm also using Firefox (latest version) with third-party cookies disabled."", 'It might be nice to have a help page about this somewhere on Wikidata.']",NA,0,I'm also using Firefox (latest version) with third-party cookies disabled.,BUG REPRODUCTION,, 15382,[Bug] Login issue with add language links widget,"Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.",1419578131,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.","Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,69,TRUE,"['Disabled noscript, but this does not make a change.', ""Even then, the ''Add link'' does not consider me to be logged in to WD.""]",NA,0,"Disabled noscript, but this does not make a change.",INVESTIGATION AND EXPLORATION,, 15382,[Bug] Login issue with add language links widget,"Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.",1419578131,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.","Disabled noscript, but this does not make a change. Even then, the ''Add link'' does not consider me to be logged in to WD.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,69,TRUE,"['Disabled noscript, but this does not make a change.', ""Even then, the ''Add link'' does not consider me to be logged in to WD.""]",NA,0,"Even then, the ''Add link'' does not consider me to be logged in to WD.",INVESTIGATION AND EXPLORATION,, 15383,[Bug] Login issue with add language links widget,">>! In T50389#832492, @Herzi.Pinki wrote: > thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript? I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.",1418933197,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#832492, @Herzi.Pinki wrote: > thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript? I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.","QUOTE QUOTE I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,68,TRUE,"[""QUOTE\nQUOTE\n\nI don't have time to test this right now, but changing your noscript settings could help (quite likely, actually)."", 'If it does, a reply about what you did would be nice, so that others can see what to do.']",NA,0,"If it does, a reply about what you did would be nice, so that others can see what to do.",CONTRIBUTION AND COMMITMENT,, 15383,[Bug] Login issue with add language links widget,">>! In T50389#832492, @Herzi.Pinki wrote: > thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript? I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.",1418933197,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#832492, @Herzi.Pinki wrote: > thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript? I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.","QUOTE QUOTE I don't have time to test this right now, but changing your noscript settings could help (quite likely, actually). If it does, a reply about what you did would be nice, so that others can see what to do.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,68,TRUE,"[""QUOTE\nQUOTE\n\nI don't have time to test this right now, but changing your noscript settings could help (quite likely, actually)."", 'If it does, a reply about what you did would be nice, so that others can see what to do.']",NA,0,"QUOTE\nQUOTE\n\nI don't have time to test this right now, but changing your noscript settings could help (quite likely, actually).",SOLUTION DISCUSSION,, 15384,[Bug] Login issue with add language links widget,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",1418083677,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?","thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""thanks hoo, but I'm using a rather old firefox and I did not update since months."", 'But I use noscript, maybe that is the problem?', 'It updates regularily.', 'Any hint on noscript?']",NA,0,"But I use noscript, maybe that is the problem?",INVESTIGATION AND EXPLORATION,, 15384,[Bug] Login issue with add language links widget,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",1418083677,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?","thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""thanks hoo, but I'm using a rather old firefox and I did not update since months."", 'But I use noscript, maybe that is the problem?', 'It updates regularily.', 'Any hint on noscript?']",NA,0,It updates regularily.,SOLUTION DISCUSSION,, 15384,[Bug] Login issue with add language links widget,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",1418083677,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?","thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""thanks hoo, but I'm using a rather old firefox and I did not update since months."", 'But I use noscript, maybe that is the problem?', 'It updates regularily.', 'Any hint on noscript?']",NA,0,Any hint on noscript?,INVESTIGATION AND EXPLORATION,, 15384,[Bug] Login issue with add language links widget,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",1418083677,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?","thanks hoo, but I'm using a rather old firefox and I did not update since months. But I use noscript, maybe that is the problem? It updates regularily. Any hint on noscript?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""thanks hoo, but I'm using a rather old firefox and I did not update since months."", 'But I use noscript, maybe that is the problem?', 'It updates regularily.', 'Any hint on noscript?']",NA,0,"thanks hoo, but I'm using a rather old firefox and I did not update since months.",SOCIAL CONVERSATION,, 15385,[Bug] Login issue with add language links widget,">>! In T50389#831804, @Herzi.Pinki wrote: > It still doesn't work for me. > To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then? Nothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).",1418081680,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,">>! In T50389#831804, @Herzi.Pinki wrote: > It still doesn't work for me. > To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then? Nothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).","QUOTE QUOTE QUOTE Nothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,66,TRUE,"['QUOTE\nQUOTE\nQUOTE\n\nNothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).']",NA,0,"QUOTE\nQUOTE\nQUOTE\n\nNothing has changed on our side, the problem is that browsers keep changing and tend to get more restrictive regarding these things (third party cookies and things like that).",INVESTIGATION AND EXPLORATION,, 15386,[Bug] Login issue with add language links widget,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",1418075179,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?","It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""It still doesn't work for me."", ""To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't ."", 'What have you changed related to authentication since then?']",NA,0,What have you changed related to authentication since then?,INVESTIGATION AND EXPLORATION,, 15386,[Bug] Login issue with add language links widget,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",1418075179,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?","It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""It still doesn't work for me."", ""To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't ."", 'What have you changed related to authentication since then?']",NA,0,It still doesn't work for me.,OBSERVED BUG BEHAVIOR,, 15386,[Bug] Login issue with add language links widget,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",1418075179,PHID-USER-cvjhvwd4dkky6b7a2tgi,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?","It still doesn't work for me. To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't . What have you changed related to authentication since then?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,66,TRUE,"[""It still doesn't work for me."", ""To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't ."", 'What have you changed related to authentication since then?']",NA,0,"To be clear about: It worked perfectly before (about 8 weeks ago), but since then it doesn't .",OBSERVED BUG BEHAVIOR,, 15387,[Bug] Login issue with add language links widget,"**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?",1416505762,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?","**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,64,TRUE,"[""**psychonaut** wrote:\n\nI'm still experiencing the problem."", ""If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?""]",NA,0,**psychonaut** wrote:\n\nI'm still experiencing the problem.,OBSERVED BUG BEHAVIOR,, 15387,[Bug] Login issue with add language links widget,"**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?",1416505762,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?","**psychonaut** wrote: I'm still experiencing the problem. If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,64,TRUE,"[""**psychonaut** wrote:\n\nI'm still experiencing the problem."", ""If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?""]",NA,0,"If it's been established definitively that this is due to the user's browser blocking third-party cookies, could a message to this effect please be added to the error message?",SOLUTION DISCUSSION,, 15388,[Bug] Login issue with add language links widget,"For me it seems fine now. Is there anything else we can do on this bug?",1413209902,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"For me it seems fine now. Is there anything else we can do on this bug?","For me it seems fine now. Is there anything else we can do on this bug?",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,58,TRUE,"['For me it seems fine now.', 'Is there anything else we can do on this bug?']",NA,0,For me it seems fine now.,OBSERVED BUG BEHAVIOR,, 15388,[Bug] Login issue with add language links widget,"For me it seems fine now. Is there anything else we can do on this bug?",1413209902,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"For me it seems fine now. Is there anything else we can do on this bug?","For me it seems fine now. Is there anything else we can do on this bug?",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,58,TRUE,"['For me it seems fine now.', 'Is there anything else we can do on this bug?']",NA,0,Is there anything else we can do on this bug?,CONTRIBUTION AND COMMITMENT,, 15389,[Bug] Login issue with add language links widget,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",1386090219,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).","(In reply to comment #11) QUOTE No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,13,TRUE,"['(In reply to comment #11)\nQUOTE\n\nNo.', 'OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose).', 'The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).']",NA,0,(In reply to comment #11)\nQUOTE\n\nNo.,SOCIAL CONVERSATION,, 15389,[Bug] Login issue with add language links widget,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",1386090219,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).","(In reply to comment #11) QUOTE No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,13,TRUE,"['(In reply to comment #11)\nQUOTE\n\nNo.', 'OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose).', 'The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).']",NA,0,"OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose).",SOLUTION DISCUSSION,, 15389,[Bug] Login issue with add language links widget,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",1386090219,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #11) > The ""real"" solution for this would be OAuth, right? No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).","(In reply to comment #11) QUOTE No. OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose). The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,13,TRUE,"['(In reply to comment #11)\nQUOTE\n\nNo.', 'OAuth could be a solution for third party client wikis, but not for Wikimedia ones (we have CentralAuth for this purpose).', 'The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).']",NA,0,The issue over here essentially comes down to a CentralAuth shortcoming (see my mail).,INVESTIGATION AND EXPLORATION,, 15390,[Bug] Login issue with add language links widget,"The ""real"" solution for this would be OAuth, right?",1386069110,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"The ""real"" solution for this would be OAuth, right?","The ""real"" solution for this would be OAuth, right?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,13,TRUE,"['The ""real"" solution for this would be OAuth, right?']",NA,0,"The ""real"" solution for this would be OAuth, right?",SOLUTION DISCUSSION,, 15391,[Bug] Login issue with add language links widget,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",1381304491,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.","**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**psychonaut** wrote:\n\nYes, I\'ve got third-party cookies disabled, though I\'d hardly call this an ""unusual"" configuration.', ""It's useful and common enough that Mozilla is considering making it the default setting for its browsers."", ""If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users."", 'In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.']",NA,0,"**psychonaut** wrote:\n\nYes, I\",SOCIAL CONVERSATION,, 15391,[Bug] Login issue with add language links widget,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",1381304491,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.","**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**psychonaut** wrote:\n\nYes, I\'ve got third-party cookies disabled, though I\'d hardly call this an ""unusual"" configuration.', ""It's useful and common enough that Mozilla is considering making it the default setting for its browsers."", ""If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users."", 'In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.']",NA,0,"d hardly call this an ""unusual"" configuration.",SOCIAL CONVERSATION,, 15391,[Bug] Login issue with add language links widget,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",1381304491,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.","**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**psychonaut** wrote:\n\nYes, I\'ve got third-party cookies disabled, though I\'d hardly call this an ""unusual"" configuration.', ""It's useful and common enough that Mozilla is considering making it the default setting for its browsers."", ""If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users."", 'In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.']",NA,0,"In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",SOLUTION DISCUSSION,, 15391,[Bug] Login issue with add language links widget,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",1381304491,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.","**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**psychonaut** wrote:\n\nYes, I\'ve got third-party cookies disabled, though I\'d hardly call this an ""unusual"" configuration.', ""It's useful and common enough that Mozilla is considering making it the default setting for its browsers."", ""If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users."", 'In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.']",NA,0,It's useful and common enough that Mozilla is considering making it the default setting for its browsers.,INVESTIGATION AND EXPLORATION,, 15391,[Bug] Login issue with add language links widget,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",1381304491,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.","**psychonaut** wrote: Yes, I've got third-party cookies disabled, though I'd hardly call this an ""unusual"" configuration. It's useful and common enough that Mozilla is considering making it the default setting for its browsers. If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users. In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['**psychonaut** wrote:\n\nYes, I\'ve got third-party cookies disabled, though I\'d hardly call this an ""unusual"" configuration.', ""It's useful and common enough that Mozilla is considering making it the default setting for its browsers."", ""If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users."", 'In the meantime, if third-party cookies are required, please update the ""You need to be logged in"" message to say so.']",NA,0,"If accepting third-party cookies is required to add interwiki links now, then if/when Mozilla makes the switch, it's going to stop working for some 20% of all Wikimedia users.",POTENTIAL NEW ISSUES AND REQUESTS,, 15392,[Bug] Login issue with add language links widget,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",1381275852,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.","This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['This can certainly happen if the user has 3rd-party cookies disabled.', ""In that case, they won't be logged into any of the other projects when the login."", ""Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly."", 'It will be hard to track down without capturing the headers when they visit the site though.', 'You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.']",NA,0,This can certainly happen if the user has 3rd-party cookies disabled.,SOLUTION USAGE,, 15392,[Bug] Login issue with add language links widget,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",1381275852,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.","This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['This can certainly happen if the user has 3rd-party cookies disabled.', ""In that case, they won't be logged into any of the other projects when the login."", ""Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly."", 'It will be hard to track down without capturing the headers when they visit the site though.', 'You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.']",NA,0,It will be hard to track down without capturing the headers when they visit the site though.,SOLUTION DISCUSSION,, 15392,[Bug] Login issue with add language links widget,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",1381275852,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.","This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['This can certainly happen if the user has 3rd-party cookies disabled.', ""In that case, they won't be logged into any of the other projects when the login."", ""Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly."", 'It will be hard to track down without capturing the headers when they visit the site though.', 'You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.']",NA,0,"You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",SOLUTION DISCUSSION,, 15392,[Bug] Login issue with add language links widget,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",1381275852,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.","This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['This can certainly happen if the user has 3rd-party cookies disabled.', ""In that case, they won't be logged into any of the other projects when the login."", ""Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly."", 'It will be hard to track down without capturing the headers when they visit the site though.', 'You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.']",NA,0,"In that case, they won't be logged into any of the other projects when the login.",SOLUTION USAGE,, 15392,[Bug] Login issue with add language links widget,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",1381275852,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.","This can certainly happen if the user has 3rd-party cookies disabled. In that case, they won't be logged into any of the other projects when the login. Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly. It will be hard to track down without capturing the headers when they visit the site though. You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['This can certainly happen if the user has 3rd-party cookies disabled.', ""In that case, they won't be logged into any of the other projects when the login."", ""Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly."", 'It will be hard to track down without capturing the headers when they visit the site though.', 'You might be able to fix this feature by using a centralauth token from the local wiki, before making the call to wikidata.']",NA,0,"Since they're not logged into wikidata when they visit wikidata directly, that does sounds like they're not being logged in properly.",INVESTIGATION AND EXPLORATION,, 15393,[Bug] Login issue with add language links widget,There are a few reports - definitely enough to make me think something is very fishy here.,1381269514,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,There are a few reports - definitely enough to make me think something is very fishy here.,There are a few reports - definitely enough to make me think something is very fishy here.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,['There are a few reports - definitely enough to make me think something is very fishy here.'],NA,0,There are a few reports - definitely enough to make me think something is very fishy here.,BUG REPRODUCTION,, 15394,[Bug] Login issue with add language links widget,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",1381268736,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).","(In reply to comment #6) QUOTE QUOTE QUOTE Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. SCREEN_NAME: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?', ""In theory you shouldn't even have to do 5)."", 'The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.', 'SCREEN_NAME: Do we often get such reports (how big is the impact of this)?', 'CCed Chris Steipp because of the SUL login issues mentioned above (point 5).']",NA,0,(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?,INVESTIGATION AND EXPLORATION,, 15394,[Bug] Login issue with add language links widget,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",1381268736,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).","(In reply to comment #6) QUOTE QUOTE QUOTE Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. SCREEN_NAME: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?', ""In theory you shouldn't even have to do 5)."", 'The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.', 'SCREEN_NAME: Do we often get such reports (how big is the impact of this)?', 'CCed Chris Steipp because of the SUL login issues mentioned above (point 5).']",NA,0,The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.,INVESTIGATION AND EXPLORATION,, 15394,[Bug] Login issue with add language links widget,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",1381268736,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).","(In reply to comment #6) QUOTE QUOTE QUOTE Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. SCREEN_NAME: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?', ""In theory you shouldn't even have to do 5)."", 'The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.', 'SCREEN_NAME: Do we often get such reports (how big is the impact of this)?', 'CCed Chris Steipp because of the SUL login issues mentioned above (point 5).']",NA,0,SCREEN_NAME: Do we often get such reports (how big is the impact of this)?,INVESTIGATION AND EXPLORATION,, 15394,[Bug] Login issue with add language links widget,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",1381268736,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).","(In reply to comment #6) QUOTE QUOTE QUOTE Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. SCREEN_NAME: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?', ""In theory you shouldn't even have to do 5)."", 'The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.', 'SCREEN_NAME: Do we often get such reports (how big is the impact of this)?', 'CCed Chris Steipp because of the SUL login issues mentioned above (point 5).']",NA,0,CCed Chris Steipp because of the SUL login issues mentioned above (point 5).,ACTION ON ISSUE,, 15394,[Bug] Login issue with add language links widget,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",1381268736,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #6) > So it seems that the ""Add links"" function *always* tells me I am not logged > in, > whether or not I really am logged in. Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. @Lydia: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).","(In reply to comment #6) QUOTE QUOTE QUOTE Do you have any uncommon settings regarding cookies? In theory you shouldn't even have to do 5). The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here. SCREEN_NAME: Do we often get such reports (how big is the impact of this)? CCed Chris Steipp because of the SUL login issues mentioned above (point 5).",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\n\nDo you have any uncommon settings regarding cookies?', ""In theory you shouldn't even have to do 5)."", 'The fact that you also have to manually log in on wikidata seems strange to me and it would be great to get more details about what exactly is going on here.', 'SCREEN_NAME: Do we often get such reports (how big is the impact of this)?', 'CCed Chris Steipp because of the SUL login issues mentioned above (point 5).']",NA,0,In theory you shouldn't even have to do 5).,SOCIAL CONVERSATION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.,BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,1,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,I visit URL According to the top of the page I am not yet logged in.,OBSERVED BUG BEHAVIOR,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,2,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I enter my username and password and click on ""Log in"".",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,I get logged in and redirected to the main page.,BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,3,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,4,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I click on ""Add links"" in the ""Languages"" section of the left bar.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"A dialog appears which says ""You need to be logged in.",OBSERVED BUG BEHAVIOR,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"You need to be logged in on this wiki and in the central data repository to use this feature"".",INVESTIGATION AND EXPLORATION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,5,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,6,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I enter my username and password and click on ""Log in"".",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,I get logged in and redirected to the main page.,BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,7,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"A dialog appears which says ""You need to be logged in.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"You need to be logged in on this wiki and in the central data repository to use this feature"".",OBSERVED BUG BEHAVIOR,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,8,NA,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",OBSERVED BUG BEHAVIOR,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,"**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https.",BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,Here's the exact series of steps which reproduces this problem:\n\n0.,BUG REPRODUCTION,, 15395,[Bug] Login issue with add language links widget,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",1381257794,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit https://en.wikipedia.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit https://en.wikipedia.org/wiki/Smriti_Irani or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit https://en.wikipedia.org/wiki/Smriti_Irani again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at https://www.wikidata.org/wiki/Special:UserLogin. This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.","**psychonaut** wrote: No, I'm logged in via my global account on both wikis via https. Here's the exact series of steps which reproduces this problem: 0. Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata. 1. I visit URL According to the top of the page I am not yet logged in. 2. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 3. I visit URL or any other article which doesn't have any interwiki links. 4. I click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 5. I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in. 6. I enter my username and password and click on ""Log in"". I get logged in and redirected to the main page. 7. I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar. A dialog appears which says ""You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature"". 8. I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in. So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,5,TRUE,"[""**psychonaut** wrote:\n\nNo, I'm logged in via my global account on both wikis via https."", ""Here's the exact series of steps which reproduces this problem:\n\n0."", 'Assume at the beginning I have just started my browser and am logged in on neither wikipedia-en nor wikidata.', '1.', 'I visit URL According to the top of the page I am not yet logged in.', '2.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '3.', ""I visit URL or any other article which doesn't have any interwiki links."", '4.', 'I click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '5.', 'I click on ""central data repository"" which takes me to a login page at URL According to the top of the page I am not yet logged in.', '6.', 'I enter my username and password and click on ""Log in"".', 'I get logged in and redirected to the main page.', '7.', 'I visit URL again and click on ""Add links"" in the ""Languages"" section of the left bar.', 'A dialog appears which says ""You need to be logged in.', 'You need to be logged in on this wiki and in the central data repository to use this feature"".', '8.', 'I click on ""central data repository"" which takes me to a login page at URL This time according to the top of the page I am already logged in.', 'So it seems that the ""Add links"" function *always* tells me I am not logged in, whether or not I really am logged in.']",NA,0,I visit URL or any other article which doesn't have any interwiki links.,OBSERVED BUG BEHAVIOR,, 15396,[Bug] Login issue with add language links widget,Tristan: Can you answer Marius' last question please?,1381155706,PHID-USER-7n5fvppwj4ueprv2iuys,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,Tristan: Can you answer Marius' last question please?,Tristan: Can you answer Marius' last question please?,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,5,TRUE,"[""Tristan: Can you answer Marius' last question please?""]",NA,0,Tristan: Can you answer Marius' last question please?,CONTRIBUTION AND COMMITMENT,, 15397,[Bug] Login issue with add language links widget,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",1368472827,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-16,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThen the above patch probably wont solve (or moreover avoid) the mentioned problem.', ""I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora."", 'The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?', ').']",NA,0,(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThen the above patch probably wont solve (or moreover avoid) the mentioned problem.,SOLUTION DISCUSSION,, 15397,[Bug] Login issue with add language links widget,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",1368472827,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-16,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThen the above patch probably wont solve (or moreover avoid) the mentioned problem.', ""I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora."", 'The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?', ').']",NA,0,The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?,INVESTIGATION AND EXPLORATION,, 15397,[Bug] Login issue with add language links widget,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",1368472827,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-16,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThen the above patch probably wont solve (or moreover avoid) the mentioned problem.', ""I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora."", 'The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?', ').']",NA,0,).,NA,, 15397,[Bug] Login issue with add language links widget,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",1368472827,PHID-USER-2mey32xhshfnf7rz7jjn,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"(In reply to comment #2) > I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) > Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed > but > will try again with them removed and post the results. Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE Then the above patch probably wont solve (or moreover avoid) the mentioned problem. I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora. The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-16,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThen the above patch probably wont solve (or moreover avoid) the mentioned problem.', ""I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora."", 'The only possible cause I can think of right now is that you are logged in via https on Wikidata.org while only being logged in via http on enwiki for some reason (different non-global accounts maybe?', ').']",NA,0,I can't reproduce this problem with neither Firefox 20 nor Seamonkey 2.17 on Fedora.,BUG REPRODUCTION,, 15398,[Bug] Login issue with add language links widget,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",1368434474,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.","**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nThe problem also occurs in safe mode (i.e., with all add-ons disabled).', ""It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS."", 'However, some further experimentation shows that the error message is triggered only sometimes.', 'Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.']",NA,0,"**psychonaut** wrote:\n\nThe problem also occurs in safe mode (i.e., with all add-ons disabled).",OBSERVED BUG BEHAVIOR,, 15398,[Bug] Login issue with add language links widget,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",1368434474,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.","**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nThe problem also occurs in safe mode (i.e., with all add-ons disabled).', ""It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS."", 'However, some further experimentation shows that the error message is triggered only sometimes.', 'Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.']",NA,0,"However, some further experimentation shows that the error message is triggered only sometimes.",INVESTIGATION AND EXPLORATION,, 15398,[Bug] Login issue with add language links widget,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",1368434474,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.","**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nThe problem also occurs in safe mode (i.e., with all add-ons disabled).', ""It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS."", 'However, some further experimentation shows that the error message is triggered only sometimes.', 'Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.']",NA,0,"Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",BUG REPRODUCTION,, 15398,[Bug] Login issue with add language links widget,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",1368434474,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.","**psychonaut** wrote: The problem also occurs in safe mode (i.e., with all add-ons disabled). It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS. However, some further experimentation shows that the error message is triggered only sometimes. Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nThe problem also occurs in safe mode (i.e., with all add-ons disabled).', ""It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS."", 'However, some further experimentation shows that the error message is triggered only sometimes.', 'Other times following the ""Add link"" gives me the ""Link with page"" popup as expected.']",NA,0,It occurs when I'm logged into and accesing Wikipedia via either HTTP or HTTPS.,OBSERVED BUG BEHAVIOR,, 15399,[Bug] Login issue with add language links widget,"**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.",1368426762,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.","**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nI experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.', 'I have a few add-ons installed but will try again with them removed and post the results.']",NA,0,**psychonaut** wrote:\n\nI experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.,BUG REPRODUCTION,, 15399,[Bug] Login issue with add language links widget,"**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.",1368426762,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,"**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.","**psychonaut** wrote: I experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17. I have a few add-ons installed but will try again with them removed and post the results.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**psychonaut** wrote:\n\nI experience this problem with Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.', 'I have a few add-ons installed but will try again with them removed and post the results.']",NA,0,I have a few add-ons installed but will try again with them removed and post the results.,BUG REPRODUCTION,, 15400,[Bug] Login issue with add language links widget,Related URL: https://gerrit.wikimedia.org/r/63393 (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf),1368391700,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mqgd5b5k4fnslwwoze2f,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/63393 (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf),Related URL: GERRIT_URL (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,['Related URL: GERRIT_URL (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf)'],NA,0,Related URL: GERRIT_URL (Gerrit Change Iae53b39dd20342f5719fd5c67d2891284f1b39bf),ISSUE CONTENT MANAGEMENT,, 15629,"give icinga a ""login"" link","**Author:** `lcarr` **Description:** **Refers To:** {T83554}",1367443030,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_description,"give icinga a ""login"" link./n/n**Author:** `lcarr` **Description:** **Refers To:** {T83554}","give icinga a ""login"" link./n/n**Author:** CODE **Description:** **Refers To:** {T83554}",Medium,50,1445408544,PHID-USER-fo56wm4wxiwpoofn2xdu,declined,TRUE,c2,1,FALSE,FALSE,-17,TRUE,"['give icinga a ""login"" link.', '**Author:** CODE\n\n**Description:**\n\n\n\n**Refers To:**\n{T83554}']",FALSE,0,"give icinga a ""login"" link.",EXPECTED BEHAVIOR,, 15629,"give icinga a ""login"" link","**Author:** `lcarr` **Description:** **Refers To:** {T83554}",1367443030,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_description,"give icinga a ""login"" link./n/n**Author:** `lcarr` **Description:** **Refers To:** {T83554}","give icinga a ""login"" link./n/n**Author:** CODE **Description:** **Refers To:** {T83554}",Medium,50,1445408544,PHID-USER-fo56wm4wxiwpoofn2xdu,declined,TRUE,c2,1,FALSE,FALSE,-17,TRUE,"['give icinga a ""login"" link.', '**Author:** CODE\n\n**Description:**\n\n\n\n**Refers To:**\n{T83554}']",FALSE,0,**Author:** CODE\n\n**Description:**\n\n\n\n**Refers To:**\n{T83554},OBSERVED BUG BEHAVIOR,, 15630,"give icinga a ""login"" link",obsolete since recently icinga-admin has been removed (!?),1424823807,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,obsolete since recently icinga-admin has been removed (!?),obsolete since recently icinga-admin has been removed (!?),NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,78,TRUE,['obsolete since recently icinga-admin has been removed (!?)'],NA,0,obsolete since recently icinga-admin has been removed (!?),ISSUE CONTENT MANAGEMENT,, 15631,"give icinga a ""login"" link",Reference to ticket #6838 added by dzahn,1408656880,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,Reference to ticket #6838 added by dzahn,Reference to ticket #6838 added by dzahn,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,51,TRUE,['Reference to ticket #6838 added by dzahn'],NA,0,Reference to ticket #6838 added by dzahn,ACTION ON ISSUE,, 15632,"give icinga a ""login"" link","%%%On Thu Aug 21 21:26:52 2014, jeremyb wrote:%%% > My best guess at the intent was to have a link somewhere on icinga to > icinga-admin. (which wasn't considered when closing?) %%%if you go to icinga, you already get a login pop-up anways, because of #6838%%%",1408656854,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,"%%%On Thu Aug 21 21:26:52 2014, jeremyb wrote:%%% > My best guess at the intent was to have a link somewhere on icinga to > icinga-admin. (which wasn't considered when closing?) %%%if you go to icinga, you already get a login pop-up anways, because of #6838%%%","%%%On Thu Aug 21 21:26:52 2014, jeremyb wrote:%%% QUOTE QUOTE %%%if you go to icinga, you already get a login pop-up anways, because of #6838%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,51,TRUE,"['%%%On Thu Aug 21 21:26:52 2014, jeremyb wrote:%%%\nQUOTE\nQUOTE\n%%%if you go to icinga, you already get a login pop-up anways, because of #6838%%%']",NA,0,"%%%On Thu Aug 21 21:26:52 2014, jeremyb wrote:%%%\nQUOTE\nQUOTE\n%%%if you go to icinga, you already get a login pop-up anways, because of #6838%%%",OBSERVED BUG BEHAVIOR,, 15633,"give icinga a ""login"" link",//AdminCc jeremyb added by jeremyb//,1408656423,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,//AdminCc jeremyb added by jeremyb//,//AdminCc jeremyb added by jeremyb//,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,51,TRUE,['//AdminCc jeremyb added by jeremyb//'],NA,0,//AdminCc jeremyb added by jeremyb//,ACTION ON ISSUE,, 15634,"give icinga a ""login"" link",//Status changed from 'resolved' to 'open' by RT_System//,1408656412,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,//Status changed from 'resolved' to 'open' by RT_System//,//Status changed from 'resolved' to 'open' by RT_System//,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,51,TRUE,"[""//Status changed from 'resolved' to 'open' by RT_System//""]",NA,0,//Status changed from 'resolved' to 'open' by RT_System//,ACTION ON ISSUE,, 15635,"give icinga a ""login"" link",%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,1408656412,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,51,TRUE,"['%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin.', ""(which wasn't considered when closing?"", ')%%%']",NA,0,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin.,INVESTIGATION AND EXPLORATION,, 15635,"give icinga a ""login"" link",%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,1408656412,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,51,TRUE,"['%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin.', ""(which wasn't considered when closing?"", ')%%%']",NA,0,)%%%,NA,, 15635,"give icinga a ""login"" link",%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,1408656412,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin. (which wasn't considered when closing?)%%%,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,51,TRUE,"['%%%My best guess at the intent was to have a link somewhere on icinga to icinga-admin.', ""(which wasn't considered when closing?"", ')%%%']",NA,0,(which wasn't considered when closing?,INVESTIGATION AND EXPLORATION,, 15636,"give icinga a ""login"" link",//Status changed from 'open' to 'resolved' by dzahn//,1396961793,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,//Status changed from 'open' to 'resolved' by dzahn//,//Status changed from 'open' to 'resolved' by dzahn//,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,31,TRUE,"[""//Status changed from 'open' to 'resolved' by dzahn//""]",NA,0,//Status changed from 'open' to 'resolved' by dzahn//,ACTION ON ISSUE,, 15637,"give icinga a ""login"" link","%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%",1396961778,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,"%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%","%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,31,TRUE,"[""%%%closing because icinga and icinga-admin both have logins.%%%\n%%%if there is an open ticket then it's to _remove_ the login on icinga (not%%%\n%%%icinga-admin) again."", '(if we can)%%%']",NA,0,(if we can)%%%,SOCIAL CONVERSATION,, 15637,"give icinga a ""login"" link","%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%",1396961778,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,"%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%","%%%closing because icinga and icinga-admin both have logins.%%% %%%if there is an open ticket then it's to _remove_ the login on icinga (not%%% %%%icinga-admin) again. (if we can)%%%",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,31,TRUE,"[""%%%closing because icinga and icinga-admin both have logins.%%%\n%%%if there is an open ticket then it's to _remove_ the login on icinga (not%%%\n%%%icinga-admin) again."", '(if we can)%%%']",NA,0,%%%closing because icinga and icinga-admin both have logins.%%%\n%%%if there is an open ticket then it's to _remove_ the login on icinga (not%%%\n%%%icinga-admin) again.,SOLUTION DISCUSSION,, 15638,"give icinga a ""login"" link",//Status changed from 'new' to 'open' by RT_System//,1392384493,PHID-USER-j3rt67f2xk5rpkgcegnj,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,//Status changed from 'new' to 'open' by RT_System//,//Status changed from 'new' to 'open' by RT_System//,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,24,TRUE,"[""//Status changed from 'new' to 'open' by RT_System//""]",NA,0,//Status changed from 'new' to 'open' by RT_System//,ACTION ON ISSUE,, 15639,"give icinga a ""login"" link",%%%resolved by https://icinga-admin.wikimedia.org ?%%%,1392384493,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,%%%resolved by https://icinga-admin.wikimedia.org ?%%%,%%%resolved by URL ?%%%,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,24,TRUE,['%%%resolved by URL ?%%%'],NA,0,%%%resolved by URL ?%%%,ACTION ON ISSUE,, 15640,"give icinga a ""login"" link",Dependency by ticket #6775 added by gage,1391627924,PHID-USER-yyzsgjllkzfxdu44eeix,PHID-TASK-wfiyhr2z2izrmo3ynbp3,task_subcomment,Dependency by ticket #6775 added by gage,Dependency by ticket #6775 added by gage,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,23,TRUE,['Dependency by ticket #6775 added by gage'],NA,0,Dependency by ticket #6775 added by gage,ISSUE CONTENT MANAGEMENT,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.,EXPECTED BEHAVIOR,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,The new UserLogin shows red links everywhere.,OBSERVED BUG BEHAVIOR,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Simple solution: kill the links (e.g.,SOLUTION DISCUSSION,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.,EXPECTED BEHAVIOR,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,URL .,NA,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed).",INVESTIGATION AND EXPLORATION,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface.",SOLUTION DISCUSSION,, 15789,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704",1367175660,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_description,"[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47704","[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default./n/nThe new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. URL . -------------------------- **Version**: 1.22.0 **Severity**: normal **See Also**: URL",Medium,50,1369167354,NA,resolved,TRUE,c2,1,TRUE,FALSE,-18,TRUE,"['[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default.', 'The new UserLogin shows red links everywhere.', ""I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed)."", 'Simple solution: kill the links (e.g.', 'createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g.', ""userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface."", ""Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g."", 'URL .', '--------------------------\n**Version**: 1.22.0\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g.",SOLUTION DISCUSSION,, 15790,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",1370675702,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFirst, thanks for translating!', 'It is gratifying to see translations appear for our work.', 'The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix.', 'When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.']",NA,0,"(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFirst, thanks for translating!",SOCIAL CONVERSATION,, 15790,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",1370675702,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFirst, thanks for translating!', 'It is gratifying to see translations appear for our work.', 'The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix.', 'When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.']",NA,0,It is gratifying to see translations appear for our work.,SOCIAL CONVERSATION,, 15790,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",1370675702,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFirst, thanks for translating!', 'It is gratifying to see translations appear for our work.', 'The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix.', 'When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.']",NA,0,"The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix.",SOLUTION DISCUSSION,, 15790,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",1370675702,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nFirst, thanks for translating!', 'It is gratifying to see translations appear for our work.', 'The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this ""wmf-"" prefix.', 'When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.']",NA,0,"When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.",SOLUTION DISCUSSION,, 15791,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.",1370508641,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-12,TRUE,"[""(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWell, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core)."", ""I don't know what the status here was exactly; cc'ing Raymond who deleted them.""]",NA,0,"(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWell, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core).",SOLUTION DISCUSSION,, 15791,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.",1370508641,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case > this wouldn<64><6E><EFBFBD>t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the > existing translations have been moved as well? Just saying. Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.","(In reply to comment #23) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-12,TRUE,"[""(In reply to comment #23)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWell, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core)."", ""I don't know what the status here was exactly; cc'ing Raymond who deleted them.""]",NA,0,I don't know what the status here was exactly; cc'ing Raymond who deleted them.,ACTION ON ISSUE,, 15792,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",1370506005,PHID-USER-7clmfrlb7fwuko4jdjbs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.","Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['Great.', 'So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch).', 'Couldn<64><6E><EFBFBD>t the existing translations have been moved as well?', 'Just saying.']",NA,0,Great.,SOCIAL CONVERSATION,, 15792,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",1370506005,PHID-USER-7clmfrlb7fwuko4jdjbs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.","Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['Great.', 'So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch).', 'Couldn<64><6E><EFBFBD>t the existing translations have been moved as well?', 'Just saying.']",NA,0,"So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch).",CONTRIBUTION AND COMMITMENT,, 15792,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",1370506005,PHID-USER-7clmfrlb7fwuko4jdjbs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.","Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['Great.', 'So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch).', 'Couldn<64><6E><EFBFBD>t the existing translations have been moved as well?', 'Just saying.']",NA,0,Couldn<64><6E><EFBFBD>t the existing translations have been moved as well?,SOLUTION DISCUSSION,, 15792,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",1370506005,PHID-USER-7clmfrlb7fwuko4jdjbs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.","Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn<64><6E><EFBFBD>t the existing translations have been moved as well? Just saying.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-12,TRUE,"['Great.', 'So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with <20><><EFBFBD>wmf-<2D><><EFBFBD> (and in case this wouldn<64><6E><EFBFBD>t be enough unnecessary work, URL was deleted, so that I couldn<64><6E><EFBFBD>t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch).', 'Couldn<64><6E><EFBFBD>t the existing translations have been moved as well?', 'Just saying.']",NA,0,Just saying.,SOCIAL CONVERSATION,, 15793,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes For WMF wikis, the three links in <https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Providing_help_links> For a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in https://www.mediawiki.org/wiki/Manual:Page_customizations",1369167354,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes For WMF wikis, the three links in <https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Providing_help_links> For a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in https://www.mediawiki.org/wiki/Manual:Page_customizations","(In reply to comment #13) QUOTE For WMF wikis, the three links in <URL For a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""(In reply to comment #13)\nQUOTE\n\nFor WMF wikis, the three links in\n<URL\n\nFor a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in URL""]",NA,0,"(In reply to comment #13)\nQUOTE\n\nFor WMF wikis, the three links in\n<URL\n\nFor a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in URL",INVESTIGATION AND EXPLORATION,, 15794,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",1368807015,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!","plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""plus'd it (not in the G kinda way)."", ""CC'ing Reedy so it is on his radar for Monday's deployment."", ""Setting back to REOPENED until the backport is done (just so we don't lose it between now and then)."", 'Thanks!']",NA,0,Thanks!,SOCIAL CONVERSATION,, 15794,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",1368807015,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!","plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""plus'd it (not in the G kinda way)."", ""CC'ing Reedy so it is on his radar for Monday's deployment."", ""Setting back to REOPENED until the backport is done (just so we don't lose it between now and then)."", 'Thanks!']",NA,0,plus'd it (not in the G kinda way).,ACTION ON ISSUE,, 15794,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",1368807015,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!","plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""plus'd it (not in the G kinda way)."", ""CC'ing Reedy so it is on his radar for Monday's deployment."", ""Setting back to REOPENED until the backport is done (just so we don't lose it between now and then)."", 'Thanks!']",NA,0,CC'ing Reedy so it is on his radar for Monday's deployment.,ACTION ON ISSUE,, 15794,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",1368807015,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!","plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""plus'd it (not in the G kinda way)."", ""CC'ing Reedy so it is on his radar for Monday's deployment."", ""Setting back to REOPENED until the backport is done (just so we don't lose it between now and then)."", 'Thanks!']",NA,0,Setting back to REOPENED until the backport is done (just so we don't lose it between now and then).,ACTION ON ISSUE ,, 15795,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.",1368758216,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.","E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"['E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change\nto the new Create account form can accompany the wmf4 roll-out.', 'Low-risk since\nthe new forms are opt-in.']",NA,0,E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change\nto the new Create account form can accompany the wmf4 roll-out.,TASK PROGRESS,, 15795,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.",1368758216,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.","E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"['E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change\nto the new Create account form can accompany the wmf4 roll-out.', 'Low-risk since\nthe new forms are opt-in.']",NA,0,Low-risk since\nthe new forms are opt-in.,ISSUE CONTENT MANAGEMENT,, 15796,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,Related URL: https://gerrit.wikimedia.org/r/64254 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),1368758105,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/64254 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,['Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df)'],NA,0,Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),TASK PROGRESS,, 15797,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Merged, so I assume this is fixed.",1368742151,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Merged, so I assume this is fixed.","Merged, so I assume this is fixed.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-15,TRUE,"['Merged, so I assume this is fixed.']",NA,0,"Merged, so I assume this is fixed.",TASK PROGRESS,, 15798,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,Related URL: https://gerrit.wikimedia.org/r/64204 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),1368739382,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/64204 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,['Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df)'],NA,0,Related URL: GERRIT_URL (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df),TASK PROGRESS,, 15799,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",1368070506,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.","That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['That would be great.', 'We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw.', 'Well, depending on my (mis)understanding of the above.']",NA,0,That would be great.,SOCIAL CONVERSATION,, 15799,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",1368070506,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.","That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['That would be great.', 'We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw.', 'Well, depending on my (mis)understanding of the above.']",NA,0,"We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw.",POTENTIAL NEW ISSUES AND REQUESTS,, 15799,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",1368070506,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.","That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['That would be great.', 'We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw.', 'Well, depending on my (mis)understanding of the above.']",NA,0,"Well, depending on my (mis)understanding of the above.",SOCIAL CONVERSATION,, 15800,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #14) > (In reply to comment #13) > > Well, I am lost. I hope that someone will compile a list of the end changes, > > of > > what admins at wikis are going to need to be told (not guess or need to > > search), and some graphic examples sound as they would be worthwhile. Also > > something that global sysops and stewards can just read and understand. > > There > > are enough changes going on for stewards to comprehend and manage without > > extra > > difficulty being imposed by convolutions. > > I'll post instructions with screenshots that are clearer, before we turn on > the > new versions as defaults, and circulate them as best I can. To clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.",1368063156,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #14) > (In reply to comment #13) > > Well, I am lost. I hope that someone will compile a list of the end changes, > > of > > what admins at wikis are going to need to be told (not guess or need to > > search), and some graphic examples sound as they would be worthwhile. Also > > something that global sysops and stewards can just read and understand. > > There > > are enough changes going on for stewards to comprehend and manage without > > extra > > difficulty being imposed by convolutions. > > I'll post instructions with screenshots that are clearer, before we turn on > the > new versions as defaults, and circulate them as best I can. To clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.","**swalling** wrote: (In reply to comment #14) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE To clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['**swalling** wrote:\n\n(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.']",NA,0,"**swalling** wrote:\n\n(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.",SOLUTION DISCUSSION,, 15801,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes, > of > what admins at wikis are going to need to be told (not guess or need to > search), and some graphic examples sound as they would be worthwhile. Also > something that global sysops and stewards can just read and understand. > There > are enough changes going on for stewards to comprehend and manage without > extra > difficulty being imposed by convolutions. I'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.",1368061177,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes, > of > what admins at wikis are going to need to be told (not guess or need to > search), and some graphic examples sound as they would be worthwhile. Also > something that global sysops and stewards can just read and understand. > There > are enough changes going on for stewards to comprehend and manage without > extra > difficulty being imposed by convolutions. I'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.","**swalling** wrote: (In reply to comment #13) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"[""**swalling** wrote:\n\n(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.""]",NA,0,"**swalling** wrote:\n\n(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.",CONTRIBUTION AND COMMITMENT,, 15802,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",1368060269,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.","Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['Well, I am lost.', 'I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile.', 'Also something that global sysops and stewards can just read and understand.', 'There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.']",NA,0,"Well, I am lost.",SOCIAL CONVERSATION,, 15802,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",1368060269,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.","Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['Well, I am lost.', 'I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile.', 'Also something that global sysops and stewards can just read and understand.', 'There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.']",NA,0,"I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile.",CONTRIBUTION AND COMMITMENT,, 15802,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",1368060269,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.","Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['Well, I am lost.', 'I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile.', 'Also something that global sysops and stewards can just read and understand.', 'There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.']",NA,0,Also something that global sysops and stewards can just read and understand.,SOLUTION DISCUSSION,, 15802,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",1368060269,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.","Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['Well, I am lost.', 'I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile.', 'Also something that global sysops and stewards can just read and understand.', 'There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.']",NA,0,There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.,SOLUTION USAGE,, 15803,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(the Gerrit bot didn't notice https://gerrit.wikimedia.org/r/#/c/61395/ , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core",1367988873,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(the Gerrit bot didn't notice https://gerrit.wikimedia.org/r/#/c/61395/ , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core","(the Gerrit bot didn't notice URL , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"[""(the Gerrit bot didn't notice URL , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df )\n\nThe gist of the Gerrit changes is\n* createacct-helpusername (slight name change) is blank by default\n* createacct-imgcaptcha-help is blank by default\nThe messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages."", 'userlogin-helplink and the helplogin-url it incorporates remain in core']",NA,0,userlogin-helplink and the helplogin-url it incorporates remain in core,OBSERVED BUG BEHAVIOR,, 15803,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(the Gerrit bot didn't notice https://gerrit.wikimedia.org/r/#/c/61395/ , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core",1367988873,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(the Gerrit bot didn't notice https://gerrit.wikimedia.org/r/#/c/61395/ , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core","(the Gerrit bot didn't notice URL , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"[""(the Gerrit bot didn't notice URL , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df )\n\nThe gist of the Gerrit changes is\n* createacct-helpusername (slight name change) is blank by default\n* createacct-imgcaptcha-help is blank by default\nThe messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages."", 'userlogin-helplink and the helplogin-url it incorporates remain in core']",NA,0,"(the Gerrit bot didn't notice URL , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df )\n\nThe gist of the Gerrit changes is\n* createacct-helpusername (slight name change) is blank by default\n* createacct-imgcaptcha-help is blank by default\nThe messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages.",OBSERVED BUG BEHAVIOR,, 15804,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,Related URL: https://gerrit.wikimedia.org/r/62570 (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9),1367908346,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/62570 (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9),Related URL: GERRIT_URL (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['Related URL: GERRIT_URL (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9)'],NA,0,Related URL: GERRIT_URL (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9),ISSUE CONTENT MANAGEMENT,, 15805,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%",1367388199,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%","**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['**swalling** wrote:\n\n%%%*** Bug 47705 has been marked as a duplicate of this bug.', '***%%%']",NA,0,**swalling** wrote:\n\n%%%*** Bug 47705 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 15805,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%",1367388199,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%","**swalling** wrote: %%%*** Bug 47705 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['**swalling** wrote:\n\n%%%*** Bug 47705 has been marked as a duplicate of this bug.', '***%%%']",NA,0,***%%%,NA,, 15806,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%",1367388158,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%","**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['**swalling** wrote:\n\n%%%*** Bug 47704 has been marked as a duplicate of this bug.', '***%%%']",NA,0,**swalling** wrote:\n\n%%%*** Bug 47704 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 15806,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%",1367388158,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%","**swalling** wrote: %%%*** Bug 47704 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"['**swalling** wrote:\n\n%%%*** Bug 47704 has been marked as a duplicate of this bug.', '***%%%']",NA,0,***%%%,NA,, 15807,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.",1367388065,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.","**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"[""**swalling** wrote:\n\nBased on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on."", ""Here's the summary version:\n\n* Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization\n* There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help\n\nI'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.""]",NA,0,"**swalling** wrote:\n\nBased on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on.",ACTION ON ISSUE,X, 15807,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.",1367388065,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.","**swalling** wrote: Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,"[""**swalling** wrote:\n\nBased on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on."", ""Here's the summary version:\n\n* Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization\n* There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help\n\nI'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.""]",NA,0,"Here's the summary version:\n\n* Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization\n* There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help\n\nI'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.",SOLUTION DISCUSSION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.,SOCIAL CONVERSATION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"The only exception is edithelppage, which you removed on en.wiki.",SOLUTION USAGE,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.",SOLUTION DISCUSSION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"In general, links are where you expect links to be (sidebar, footer) and it\",INVESTIGATION AND EXPLORATION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"s what we have MediaWiki pages for, you just find a message where you want the link and edit it.",SOCIAL CONVERSATION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",MOTIVATION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,"I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin.",SOLUTION DISCUSSION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff.,SOCIAL CONVERSATION,, 15808,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",1367303425,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.","(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. QUOTE QUOTE QUOTE QUOTE I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always ""apparent"" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThank you for the link.', ""I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin."", 'The only exception is edithelppage, which you removed on en.wiki.', ""QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't see any tradeoff."", 'In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people.', 'In general, links are where you expect links to be (sidebar, footer) and it\'s always ""apparent"" how to add more elsewhere: it\'s what we have MediaWiki pages for, you just find a message where you want the link and edit it.', 'The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.']",NA,0,apparent,NA,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.",SOLUTION DISCUSSION,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,"I added the three urls introduced by the new forms there, it will change as we work through these bugs.",CONTRIBUTION AND COMMITMENT,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.,POTENTIAL NEW ISSUES AND REQUESTS,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,"(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)",INVESTIGATION AND EXPLORATION,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,If we make them blank by default it's less apparent how those wikis can deliver the better experience.,SOLUTION USAGE,, 15809,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",1367268935,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.","To be specific, the three URLs assumed by the new login and create account ""VForm""s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) URL lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['To be specific, the three URLs assumed by the new login and create account ""VForm""s are\n* createacct-helpusername-url discussed in bug 47704\n* helplogin-url\n* createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha)\n\nURL lists all the pages that a wiki already needs to create to avoid red links.', ""(I only found this page just now, it is unfortunate that the installation instructions don't mention it.)"", 'I added the three urls introduced by the new forms there, it will change as we work through these bugs.', 'These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well.', ""If we make them blank by default it's less apparent how those wikis can deliver the better experience."", ""It's a tradeoff.""]",NA,0,It's a tradeoff.,SOCIAL CONVERSATION,, 15810,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,I commented laying out options for the username link at https://bugzilla.wikimedia.org/show_bug.cgi?id=47704#c12 .,1367268215,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,I commented laying out options for the username link at https://bugzilla.wikimedia.org/show_bug.cgi?id=47704#c12 .,I commented laying out options for the username link at URL .,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,['I commented laying out options for the username link at URL .'],NA,0,I commented laying out options for the username link at URL .,TASK PROGRESS,, 15811,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #3) > This seems related to bug 47704. Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.",1367220727,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #3) > This seems related to bug 47704. Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.","(In reply to comment #3) QUOTE Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #3)\nQUOTE\n\nYes, but that would be only a partial fix of the problem.', ""Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.""]",NA,0,"(In reply to comment #3)\nQUOTE\n\nYes, but that would be only a partial fix of the problem.",SOLUTION DISCUSSION,, 15811,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #3) > This seems related to bug 47704. Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.",1367220727,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #3) > This seems related to bug 47704. Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.","(In reply to comment #3) QUOTE Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #3)\nQUOTE\n\nYes, but that would be only a partial fix of the problem.', ""Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.""]",NA,0,"Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.",SOCIAL CONVERSATION,X, 15812,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,This seems related to bug 47704.,1367193931,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,This seems related to bug 47704.,This seems related to bug 47704.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,['This seems related to bug 47704.'],NA,0,This seems related to bug 47704.,ISSUE CONTENT MANAGEMENT,, 15813,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"(In reply to comment #1) > we are leaving the red links in and encouraging people to either edit the > message locally or simply redirect the links to the appropriate title. Annoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.",1367176754,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"(In reply to comment #1) > we are leaving the red links in and encouraging people to either edit the > message locally or simply redirect the links to the appropriate title. Annoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.","(In reply to comment #1) QUOTE QUOTE Annoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nAnnoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.']",NA,0,"(In reply to comment #1)\nQUOTE\nQUOTE\n\nAnnoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.",SOLUTION DISCUSSION,, 15814,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",1367176032,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.","**swalling** wrote: (In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE As noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['**swalling** wrote:\n\n(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAs noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title.', 'This is why redirects were invented.', 'Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form.', ""For third party users, it's one of several things they may need to customize.""]",NA,0,**swalling** wrote:\n\n(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAs noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title.,SOLUTION DISCUSSION,, 15814,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",1367176032,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.","**swalling** wrote: (In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE As noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['**swalling** wrote:\n\n(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAs noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title.', 'This is why redirects were invented.', 'Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form.', ""For third party users, it's one of several things they may need to customize.""]",NA,0,This is why redirects were invented.,SOCIAL CONVERSATION,, 15814,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",1367176032,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.","**swalling** wrote: (In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE As noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['**swalling** wrote:\n\n(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAs noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title.', 'This is why redirects were invented.', 'Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form.', ""For third party users, it's one of several things they may need to customize.""]",NA,0,"Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form.",SOLUTION DISCUSSION,, 15814,[New UserLogin] Convert Wikimedia-specific messages to be blank in core by default,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",1367176032,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-w4lc7xuaj5ne3qtkzs43,task_subcomment,"**swalling** wrote: (In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.","**swalling** wrote: (In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE As noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['**swalling** wrote:\n\n(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAs noted in URL we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title.', 'This is why redirects were invented.', 'Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form.', ""For third party users, it's one of several things they may need to customize.""]",NA,0,"For third party users, it's one of several things they may need to customize.",SOLUTION USAGE,, 15887,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"When editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",1362608760,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-nmf7tpcq5shuju5asec2,task_description,"Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1370996903,NA,resolved,TRUE,c2,1,FALSE,FALSE,-25,TRUE,"['Parsoid: Redirects should not be served as HTTP 200 with contents of target.', 'When editing page with redirect, I can edit just the page to where it is redirected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Parsoid: Redirects should not be served as HTTP 200 with contents of target.,EXPECTED BEHAVIOR,, 15887,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"When editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",1362608760,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-nmf7tpcq5shuju5asec2,task_description,"Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1370996903,NA,resolved,TRUE,c2,1,FALSE,FALSE,-25,TRUE,"['Parsoid: Redirects should not be served as HTTP 200 with contents of target.', 'When editing page with redirect, I can edit just the page to where it is redirected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"When editing page with redirect, I can edit just the page to where it is redirected.",SOLUTION DISCUSSION,, 15887,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"When editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",1362608760,PHID-USER-vm462i2ffbawnuo4mh3n,PHID-TASK-nmf7tpcq5shuju5asec2,task_description,"Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal","Parsoid: Redirects should not be served as HTTP 200 with contents of target./n/nWhen editing page with redirect, I can edit just the page to where it is redirected. -------------------------- **Version**: unspecified **Severity**: normal",Medium,50,1370996903,NA,resolved,TRUE,c2,1,FALSE,FALSE,-25,TRUE,"['Parsoid: Redirects should not be served as HTTP 200 with contents of target.', 'When editing page with redirect, I can edit just the page to where it is redirected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 15888,Parsoid: Redirects should not be served as HTTP 200 with contents of target,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],1372934103,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']",NA,0,[Parsoid component reorg by merging JS/General and General.,SOLUTION DISCUSSION,, 15888,Parsoid: Redirects should not be served as HTTP 200 with contents of target,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],1372934103,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']",NA,0,See bug 50685 for more information.,ISSUE CONTENT MANAGEMENT,, 15888,Parsoid: Redirects should not be served as HTTP 200 with contents of target,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],1372934103,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']",NA,0,Filter bugmail on this comment.,SOCIAL CONVERSATION,, 15888,Parsoid: Redirects should not be served as HTTP 200 with contents of target,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],1372934103,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-8,TRUE,"['[Parsoid component reorg by merging JS/General and General.', 'See bug 50685 for more information.', 'Filter bugmail on this comment.', 'parsoidreorg20130704]']",NA,0,parsoidreorg20130704],NA,, 15889,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.",1370996903,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.","I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-11,TRUE,"['I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected.', 'Closing as fixed.']",NA,0,"I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected.",TASK PROGRESS,, 15889,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.",1370996903,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.","I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected. Closing as fixed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-11,TRUE,"['I removed our previous behavior of following redirects when encountering a redirect page, so we now return the regular redirect content as expected.', 'Closing as fixed.']",NA,0,Closing as fixed.,ACTION ON ISSUE,, 15890,Parsoid: Redirects should not be served as HTTP 200 with contents of target,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,1368776564,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects."", 'One more patch is needed to change the http status and turn off the old redirect code.', 'Reopening.']",NA,0,One more patch is needed to change the http status and turn off the old redirect code.,SOLUTION DISCUSSION,, 15890,Parsoid: Redirects should not be served as HTTP 200 with contents of target,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,1368776564,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects."", 'One more patch is needed to change the http status and turn off the old redirect code.', 'Reopening.']",NA,0,Reopening.,ACTION ON ISSUE,, 15890,Parsoid: Redirects should not be served as HTTP 200 with contents of target,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,1368776564,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects. One more patch is needed to change the http status and turn off the old redirect code. Reopening.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"[""Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects."", 'One more patch is needed to change the http status and turn off the old redirect code.', 'Reopening.']",NA,0,Sorry: the wikitext parsing bit landed but I didn't yet make any changes to how the server handles redirects.,TASK PROGRESS,, 15891,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).",1368771676,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).","I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"['I have not tested the HTTP responses yet, but am happy to close.', 'Please reopen if you find issues (or open a new bug).']",NA,0,"I have not tested the HTTP responses yet, but am happy to close.",TESTING,, 15891,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).",1368771676,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).","I have not tested the HTTP responses yet, but am happy to close. Please reopen if you find issues (or open a new bug).",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-15,TRUE,"['I have not tested the HTTP responses yet, but am happy to close.', 'Please reopen if you find issues (or open a new bug).']",NA,0,Please reopen if you find issues (or open a new bug).,ACTION ON ISSUE ,, 15892,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"As the gerrit commit is merged, can this now be closed?",1368771580,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"As the gerrit commit is merged, can this now be closed?","As the gerrit commit is merged, can this now be closed?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-15,TRUE,"['As the gerrit commit is merged, can this now be closed?']",NA,0,"As the gerrit commit is merged, can this now be closed?",ACTION ON ISSUE ,, 15893,Parsoid: Redirects should not be served as HTTP 200 with contents of target,*** Bug 48271 has been marked as a duplicate of this bug. ***,1368568441,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,*** Bug 48271 has been marked as a duplicate of this bug. ***,*** Bug 48271 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['*** Bug 48271 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 48271 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 15893,Parsoid: Redirects should not be served as HTTP 200 with contents of target,*** Bug 48271 has been marked as a duplicate of this bug. ***,1368568441,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,*** Bug 48271 has been marked as a duplicate of this bug. ***,*** Bug 48271 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-16,TRUE,"['*** Bug 48271 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA ,, 15894,Parsoid: Redirects should not be served as HTTP 200 with contents of target,Related URL: https://gerrit.wikimedia.org/r/61799 (Gerrit Change I1bd36f32a5e46b90261895e5499a0308875e5e05),1367429750,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,Related URL: https://gerrit.wikimedia.org/r/61799 (Gerrit Change I1bd36f32a5e46b90261895e5499a0308875e5e05),Related URL: GERRIT_URL (Gerrit Change I1bd36f32a5e46b90261895e5499a0308875e5e05),NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-17,TRUE,['Related URL: GERRIT_URL (Gerrit Change I1bd36f32a5e46b90261895e5499a0308875e5e05)'],NA,0,Related URL: GERRIT_URL (Gerrit Change I1bd36f32a5e46b90261895e5499a0308875e5e05),ISSUE CONTENT MANAGEMENT,, 15895,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"""#REDIRECT [[www.google.com]]"" behaves just the same way as ""#REDIRECT [[Foo]]"", so not that unexpected.",1367351972,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"""#REDIRECT [[www.google.com]]"" behaves just the same way as ""#REDIRECT [[Foo]]"", so not that unexpected.","""#REDIRECT [[www.google.com]]"" behaves just the same way as ""#REDIRECT [[Foo]]"", so not that unexpected.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['""#REDIRECT [[www.google.com]]"" behaves just the same way as ""#REDIRECT [[Foo]]"", so not that unexpected.']",NA,0,"""#REDIRECT [[www.google.com]]"" behaves just the same way as ""#REDIRECT [[Foo]]"", so not that unexpected.",INVESTIGATION AND EXPLORATION,, 15896,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Note: test ""#REDIRECT [[www.google.com]]"" which currently does unusual things.",1367350491,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Note: test ""#REDIRECT [[www.google.com]]"" which currently does unusual things.","Note: test ""#REDIRECT [[www.google.com]]"" which currently does unusual things.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-18,TRUE,"['Note: test ""#REDIRECT [[www.google.com]]"" which currently does unusual things.']",NA,0,"Note: test ""#REDIRECT [[www.google.com]]"" which currently does unusual things.",TESTING,, 15897,Parsoid: Redirects should not be served as HTTP 200 with contents of target,See http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Redirects for the preliminary DOM spec.,1366225211,PHID-USER-hbtlbu4zftxnz4i6f7yf,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,See http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Redirects for the preliminary DOM spec.,See URL for the preliminary DOM spec.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,['See URL for the preliminary DOM spec.'],NA,0,See URL for the preliminary DOM spec.,ISSUE CONTENT MANAGEMENT,, 15898,Parsoid: Redirects should not be served as HTTP 200 with contents of target,See bug 47328 for the corresponding Visual Editor bug.,1366223242,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,See bug 47328 for the corresponding Visual Editor bug.,See bug 47328 for the corresponding Visual Editor bug.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,['See bug 47328 for the corresponding Visual Editor bug.'],NA,0,See bug 47328 for the corresponding Visual Editor bug.,ISSUE CONTENT MANAGEMENT,, 15899,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",1366221726,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)","From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\'s an <ol>\ngwicke: obviously we\'d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \'stuff\' in a redirect?', 'gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.', 'gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)']",NA,0,"From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\",SOLUTION DISCUSSION,, 15899,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",1366221726,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)","From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\'s an <ol>\ngwicke: obviously we\'d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \'stuff\' in a redirect?', 'gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.', 'gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)']",NA,0,"d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \",SOLUTION DISCUSSION,, 15899,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",1366221726,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)","From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\'s an <ol>\ngwicke: obviously we\'d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \'stuff\' in a redirect?', 'gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.', 'gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)']",NA,0, in a redirect?,INVESTIGATION AND EXPLORATION,, 15899,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",1366221726,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)","From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\'s an <ol>\ngwicke: obviously we\'d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \'stuff\' in a redirect?', 'gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.', 'gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)']",NA,0,gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.,SOLUTION DISCUSSION,, 15899,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",1366221726,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)","From IRC discussion w/ GWicke: gwicke: I think that we should not resolve redirects for top-level requests gwicke: should return a meta instead that lets the VE edit the redirect cscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that's an <ol> gwicke: obviously we'd expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that cscott-free: i think i learned recently that there can be other 'stuff' in a redirect? gwicke: arguably this should eventually end up in the head instead of the content gwicke: but for now we should probably keep it in the content area in the interest of round-tripping cscott-free: that makes sense. gwicke: cscott: there can be page content following it that is normally ignored by MW gwicke: but we should probably still round-trip it gwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head (01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo""> (01:58:08 PM) gwicke: maybe we should use link / rel / href again (01:58:21 PM) gwicke: for the same relative link resolution reasons (see bug 45206 comment 5 for a brief discussion of the meta/link issues)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['From IRC discussion w/ GWicke:\n\ngwicke: I think that we should not resolve redirects for top-level requests\ngwicke: should return a meta instead that lets the VE edit the redirect\ncscott-free: yeah, although editing ""#REDIRECT [[foo]]"" is a bit awkward, that\'s an <ol>\ngwicke: obviously we\'d expose it as <meta property=""mw:Redirect"" content=""foo""> or something like that\ncscott-free: i think i learned recently that there can be other \'stuff\' in a redirect?', 'gwicke: arguably this should eventually end up in the head instead of the content\ngwicke: but for now we should probably keep it in the content area in the interest of round-tripping\ncscott-free: that makes sense.', 'gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)']",NA,0,"gwicke: cscott: there can be page content following it that is normally ignored by MW\ngwicke: but we should probably still round-trip it\ngwicke: hence the idea to keep it inline for now rather than returning a blank body with meta info in the head\n(01:58:07 PM) cscott-free: i suspect there should be a corresponding VE bug for editing the <meta property=""mw:Redirect"" content=""foo"">\n(01:58:08 PM) gwicke: maybe we should use link / rel / href again\n(01:58:21 PM) gwicke: for the same relative link resolution reasons\n\n(see bug 45206 comment 5 for a brief discussion of the meta/link issues)",POTENTIAL NEW ISSUES AND REQUESTS,, 15900,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"If you ask Parsoid for (say) http://localhost:8000/en/OLPC you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.",1366221094,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"If you ask Parsoid for (say) http://localhost:8000/en/OLPC you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.","If you ask Parsoid for (say) URL you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['If you ask Parsoid for (say) URL you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article.', ""So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.""]",NA,0,"If you ask Parsoid for (say) URL you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article.",OBSERVED BUG BEHAVIOR,, 15900,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"If you ask Parsoid for (say) http://localhost:8000/en/OLPC you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.",1366221094,PHID-USER-m2ezqyeb4uz67zq6bats,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"If you ask Parsoid for (say) http://localhost:8000/en/OLPC you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.","If you ask Parsoid for (say) URL you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article. So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-19,TRUE,"['If you ask Parsoid for (say) URL you get the page for ""One Laptop Per Child"" (the <title> is correct), but the returned page contains {{Redirect|OLPC}} in addition to the text from the ""One Laptop Per Child"" article.', ""So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.""]",NA,0,"So in addition to the redirect being transparent, we're also getting bogus extra content in the parsed version.",INVESTIGATION AND EXPLORATION,, 15901,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",1362760613,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.","Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Juan,\n\nThanks for your bug report; you are correct.', 'This is because Parsoid gives the wrong response for pages with redirects.', 'Pushing over to them.', ""Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)"", 'Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.']",NA,0,"Juan,\n\nThanks for your bug report; you are correct.",SOCIAL CONVERSATION,, 15901,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",1362760613,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.","Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Juan,\n\nThanks for your bug report; you are correct.', 'This is because Parsoid gives the wrong response for pages with redirects.', 'Pushing over to them.', ""Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)"", 'Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.']",NA,0,This is because Parsoid gives the wrong response for pages with redirects.,INVESTIGATION AND EXPLORATION,, 15901,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",1362760613,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.","Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Juan,\n\nThanks for your bug report; you are correct.', 'This is because Parsoid gives the wrong response for pages with redirects.', 'Pushing over to them.', ""Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)"", 'Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.']",NA,0,Pushing over to them.,ACTION ON ISSUE ,, 15901,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",1362760613,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.","Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Juan,\n\nThanks for your bug report; you are correct.', 'This is because Parsoid gives the wrong response for pages with redirects.', 'Pushing over to them.', ""Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)"", 'Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.']",NA,0,"Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",EXPECTED BEHAVIOR,, 15901,Parsoid: Redirects should not be served as HTTP 200 with contents of target,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",1362760613,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-nmf7tpcq5shuju5asec2,task_subcomment,"Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.","Juan, Thanks for your bug report; you are correct. This is because Parsoid gives the wrong response for pages with redirects. Pushing over to them. Current behaviour: * 200 response with the contents of the target page On what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300): Expected behaviour - type A: * when in 'reading mode', a 302 to the page with the redirect; * when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.) Expected behaviour - type B: * a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Juan,\n\nThanks for your bug report; you are correct.', 'This is because Parsoid gives the wrong response for pages with redirects.', 'Pushing over to them.', ""Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)"", 'Expected behaviour - type B:\n* a 300 response with the first link (for regular browsers) being off to the target of the page, and the second being the ?redirect=no or whatever version to be able to edit it.']",NA,0,"Current behaviour:\n* 200 response with the contents of the target page\n\n\nOn what we'd expect, I'd suggest either type A (but it's messy architecturally) or type B (but not sure about user agent support for HTTP 300):\n\nExpected behaviour - type A:\n* when in 'reading mode', a 302 to the page with the redirect;\n* when in 'editing mode', a 200 with the contents of the page (to edit the redirect / etc.)",OBSERVED BUG BEHAVIOR,, 15902,Clear specific user's watchlist that is too large to load (HTTP Error 500),"**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist",1361825880,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tacmfcmzyzppgwxzok5o,task_description,"Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist","Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** CODE **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See URL -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1362147678,NA,resolved,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"[""Clear specific user's watchlist that is too large to load (HTTP Error 500)."", '**Author:** CODE\n\n**Description:**\nPlease clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it.', 'See URL\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",TRUE,0,**Author:** CODE\n\n**Description:**\nPlease clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it.,OBSERVED BUG BEHAVIOR,, 15902,Clear specific user's watchlist that is too large to load (HTTP Error 500),"**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist",1361825880,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tacmfcmzyzppgwxzok5o,task_description,"Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist","Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** CODE **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See URL -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1362147678,NA,resolved,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"[""Clear specific user's watchlist that is too large to load (HTTP Error 500)."", '**Author:** CODE\n\n**Description:**\nPlease clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it.', 'See URL\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",TRUE,0,See URL\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL,OBSERVED BUG BEHAVIOR,, 15902,Clear specific user's watchlist that is too large to load (HTTP Error 500),"**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist",1361825880,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tacmfcmzyzppgwxzok5o,task_description,"Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** `mattbisanz` **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=540347817#Cannot_edit_watchlist","Clear specific user's watchlist that is too large to load (HTTP Error 500)./n/n**Author:** CODE **Description:** Please clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it. See URL -------------------------- **Version**: wmf-deployment **Severity**: normal **URL**: URL",Medium,50,1362147678,NA,resolved,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"[""Clear specific user's watchlist that is too large to load (HTTP Error 500)."", '**Author:** CODE\n\n**Description:**\nPlease clear the watchlist of user Carlossuarez46 at en.wp because it has become too large for him to load the page and edit it.', 'See URL\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",TRUE,0,Clear specific user's watchlist that is too large to load (HTTP Error 500).,OBSERVED BUG BEHAVIOR,, 15903,Clear specific user's watchlist that is too large to load (HTTP Error 500),Max Semenik cleared my watchlist on Commons,1362147678,PHID-USER-j4jntnatcouoxfrk74sh,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,Max Semenik cleared my watchlist on Commons,Max Semenik cleared my watchlist on Commons,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-26,TRUE,['Max Semenik cleared my watchlist on Commons'],NA,0,Max Semenik cleared my watchlist on Commons,SOCIAL CONVERSATION,, 15904,Clear specific user's watchlist that is too large to load (HTTP Error 500),"For future reference, please file a separate request to track, otherwise this specific bug report would never be closed.",1362076855,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,"For future reference, please file a separate request to track, otherwise this specific bug report would never be closed.","For future reference, please file a separate request to track, otherwise this specific bug report would never be closed.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-26,TRUE,"['For future reference, please file a separate request to track, otherwise this specific bug report would never be closed.']",NA,0,"For future reference, please file a separate request to track, otherwise this specific bug report would never be closed.",ISSUE CONTENT MANAGEMENT,, 15905,Clear specific user's watchlist that is too large to load (HTTP Error 500),Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,1362065923,PHID-USER-j4jntnatcouoxfrk74sh,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-26,TRUE,"['Can you also do the same for Jarekt on Commons.', 'I am also unable to edit my watchlist.']",NA,0,Can you also do the same for Jarekt on Commons.,CONTRIBUTION AND COMMITMENT,, 15905,Clear specific user's watchlist that is too large to load (HTTP Error 500),Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,1362065923,PHID-USER-j4jntnatcouoxfrk74sh,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,Can you also do the same for Jarekt on Commons. I am also unable to edit my watchlist.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-26,TRUE,"['Can you also do the same for Jarekt on Commons.', 'I am also unable to edit my watchlist.']",NA,0,I am also unable to edit my watchlist.,BUG REPRODUCTION,, 15906,Clear specific user's watchlist that is too large to load (HTTP Error 500),"mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>",1362010363,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,"mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>","mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-26,TRUE,"['mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 221044 |\n+----------+\n1 row in set (0.12 sec)\n\n\nSeriously?', 'mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407;\nQuery OK, 221044 rows affected (1 min 53.68 sec)\n\nmysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 0 |\n+----------+\n1 row in set (0.07 sec)\n\nmysql:wikiadmin@db1017 [enwiki]>']",NA,0,mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 221044 |\n+----------+\n1 row in set (0.12 sec)\n\n\nSeriously?,NA,, 15906,Clear specific user's watchlist that is too large to load (HTTP Error 500),"mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>",1362010363,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tacmfcmzyzppgwxzok5o,task_subcomment,"mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>","mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 221044 | +----------+ 1 row in set (0.12 sec) Seriously? mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407; Query OK, 221044 rows affected (1 min 53.68 sec) mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec) mysql:wikiadmin@db1017 [enwiki]>",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-26,TRUE,"['mysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 221044 |\n+----------+\n1 row in set (0.12 sec)\n\n\nSeriously?', 'mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407;\nQuery OK, 221044 rows affected (1 min 53.68 sec)\n\nmysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 0 |\n+----------+\n1 row in set (0.07 sec)\n\nmysql:wikiadmin@db1017 [enwiki]>']",NA,0,"mysql:wikiadmin@db1017 [enwiki]> delete from watchlist where wl_user=23407;\nQuery OK, 221044 rows affected (1 min 53.68 sec)\n\nmysql:wikiadmin@db1017 [enwiki]> select count(*) from watchlist where wl_user=23407;\n+----------+\n| count(*) |\n+----------+\n| 0 |\n+----------+\n1 row in set (0.07 sec)\n\nmysql:wikiadmin@db1017 [enwiki]>",OBSERVED BUG BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.,EXPECTED BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,certificate or CA problems).,NA,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.,EXPECTED BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.",OBSERVED BUG BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.,EXPECTED BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,self-signed) certificate.,NA,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,"Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.",EXPECTED BEHAVIOR,, 15907,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"OpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",1361700900,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_description,"[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an https://OpenID: show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal","[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems)./n/nOpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g. self-signed) CA Currently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted. Inform the user that the verification failed because the OpenID server uses an untrusted (e.g. self-signed) certificate. Additional improvements: + allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have) + allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action. (nice to have for testing) -------------------------- **Version**: master **Severity**: normal",Medium,50,1363539993,NA,declined,TRUE,c2,1,FALSE,FALSE,-27,TRUE,"['[SSL] OpenID consumer when authenticating an URL show a distinct verification error message in case of host verification failures (e.g.', 'certificate or CA problems).', 'OpenID consumer when authentication an URL show a distinct verification error message in case of untrusted (e.g.', 'self-signed) CA\n\nCurrently, you see only the general message ""Verification error"", even when the consumer wiki knows that the CA is untrusted.', 'Inform the user that the verification failed because the OpenID server uses an untrusted (e.g.', 'self-signed) certificate.', 'Additional improvements:\n\n+ allow to show the server certificate fingerprints (sha-256, sha-1, md5) (must have)\n+ allow to overwrite the single CA error(warning) and accept even an untrusted OpenID on extra user action.', '(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,0,(nice to have for testing)\n\n--------------------------\n**Version**: master\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 15908,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .",1363539993,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .","I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"['I analysed the issue and found that it is an ""upstream"" problem of the php-openid library.', 'The problem is not jeopardizing the security.', 'The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .']",NA,0,"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library.",INVESTIGATION AND EXPLORATION,, 15908,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .",1363539993,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .","I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"['I analysed the issue and found that it is an ""upstream"" problem of the php-openid library.', 'The problem is not jeopardizing the security.', 'The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .']",NA,0,The problem is not jeopardizing the security.,INVESTIGATION AND EXPLORATION,, 15908,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .",1363539993,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as https://github.com/openid/php-openid/pull/92 .","I analysed the issue and found that it is an ""upstream"" problem of the php-openid library. The problem is not jeopardizing the security. The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"['I analysed the issue and found that it is an ""upstream"" problem of the php-openid library.', 'The problem is not jeopardizing the security.', 'The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .']",NA,0,"The distinct verification error message can only be shown, when the underlying php-openid library includes my patch which is sent as URL .",INVESTIGATION AND EXPLORATION,, 15909,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),+ http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/,1363443570,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,+ http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/,+ URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,['+ URL'],NA,0,+ URL,NA,, 15910,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"*** this is not yet a proposed patch *** see http://www.php.net/manual/de/function.curl-setopt.php for curl options ad-hoc possibility to disable host certificate checks https://gerrit.wikimedia.org/r/#/c/54123/1 : in OpenID.php, or in your LocalSettings.php (after including the extension) add /** * When this wiki is used as consumer: * * Whether OpenID https://provider-host certificates are checked (default) * * true enables SSL Certificate check * this is the default even when the define statement is missing * * set to false if you want to disable SSL Certificate check * this can only by useful for testing with self-signed certificates */ define( 'Auth_OpenID_VERIFY_HOST', true ); In a forthcoming version of the extension this can be part of new settings per-provider.",1363431663,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"*** this is not yet a proposed patch *** see http://www.php.net/manual/de/function.curl-setopt.php for curl options ad-hoc possibility to disable host certificate checks https://gerrit.wikimedia.org/r/#/c/54123/1 : in OpenID.php, or in your LocalSettings.php (after including the extension) add /** * When this wiki is used as consumer: * * Whether OpenID https://provider-host certificates are checked (default) * * true enables SSL Certificate check * this is the default even when the define statement is missing * * set to false if you want to disable SSL Certificate check * this can only by useful for testing with self-signed certificates */ define( 'Auth_OpenID_VERIFY_HOST', true ); In a forthcoming version of the extension this can be part of new settings per-provider.","*** this is not yet a proposed patch *** see URL for curl options ad-hoc possibility to disable host certificate checks URL : in OpenID.php, or in your LocalSettings.php (after including the extension) add /** * When this wiki is used as consumer: * * Whether OpenID URL certificates are checked (default) * * true enables SSL Certificate check * this is the default even when the define statement is missing * * set to false if you want to disable SSL Certificate check * this can only by useful for testing with self-signed certificates */ define( 'Auth_OpenID_VERIFY_HOST', true ); In a forthcoming version of the extension this can be part of new settings per-provider.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"[""*** this is not yet a proposed patch ***\n\nsee URL for curl options\n\nad-hoc possibility to disable host certificate checks URL :\n\nin OpenID.php, or in your LocalSettings.php (after including the extension) add\n\n/**\n * When this wiki is used as consumer:\n *\n * Whether OpenID URL certificates are checked (default)\n *\n * true enables SSL Certificate check\n * this is the default even when the define statement is missing\n *\n * set to false if you want to disable SSL Certificate check\n * this can only by useful for testing with self-signed certificates\n */\ndefine( 'Auth_OpenID_VERIFY_HOST', true );\n\nIn a forthcoming version of the extension this can be part of new settings per-provider.""]",NA,0,"*** this is not yet a proposed patch ***\n\nsee URL for curl options\n\nad-hoc possibility to disable host certificate checks URL :\n\nin OpenID.php, or in your LocalSettings.php (after including the extension) add\n\n/**\n * When this wiki is used as consumer:\n *\n * Whether OpenID URL certificates are checked (default)\n *\n * true enables SSL Certificate check\n * this is the default even when the define statement is missing\n *\n * set to false if you want to disable SSL Certificate check\n * this can only by useful for testing with self-signed certificates\n */\ndefine( 'Auth_OpenID_VERIFY_HOST', true );\n\nIn a forthcoming version of the extension this can be part of new settings per-provider.",FUTURE PLANS,, 15911,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"Just for the record: logfile looks like [error] Got no response code when fetching https://provider/phase3/index.php/User:Username, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung",1363427587,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"Just for the record: logfile looks like [error] Got no response code when fetching https://provider/phase3/index.php/User:Username, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung","Just for the record: logfile looks like [error] Got no response code when fetching URL referer: URL [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"['Just for the record: logfile looks like\n\n[error] Got no response code when fetching URL referer: URL\n\n[error] CURL error (60): SSL certificate problem, verify that the CA cert is OK.', 'Details:\\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: URL']",NA,0,"Just for the record: logfile looks like\n\n[error] Got no response code when fetching URL referer: URL\n\n[error] CURL error (60): SSL certificate problem, verify that the CA cert is OK.",OBSERVED BUG BEHAVIOR,, 15911,[SSL] OpenID consumer when authenticating an https://OpenID: show a distinct verification error message in case of host verification failures (e.g. certificate or CA problems),"Just for the record: logfile looks like [error] Got no response code when fetching https://provider/phase3/index.php/User:Username, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung",1363427587,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-7xp3ch6l5wqsr55n4fbo,task_subcomment,"Just for the record: logfile looks like [error] Got no response code when fetching https://provider/phase3/index.php/User:Username, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: http://consumer/index.php/Spezial:OpenID-Umwandlung","Just for the record: logfile looks like [error] Got no response code when fetching URL referer: URL [error] CURL error (60): SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-24,TRUE,"['Just for the record: logfile looks like\n\n[error] Got no response code when fetching URL referer: URL\n\n[error] CURL error (60): SSL certificate problem, verify that the CA cert is OK.', 'Details:\\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: URL']",NA,0,"Details:\\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed, referer: URL",OBSERVED BUG BEHAVIOR,, 15920,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",1360293600,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_description,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major","Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View URL * Click ""View Attachment as Diff"" Request url: URL This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",Medium,50,1398336250,NA,resolved,TRUE,c2,1,TRUE,FALSE,-29,TRUE,"['Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only).', '* View URL\n* Click ""View Attachment as Diff""\n\n\nRequest url:\nURL\n\nThis makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS.', '--------------------------\n**Version**: unspecified\n**Severity**: major']",FALSE,0,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only).",OBSERVED BUG BEHAVIOR,, 15920,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",1360293600,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_description,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major","Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View URL * Click ""View Attachment as Diff"" Request url: URL This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",Medium,50,1398336250,NA,resolved,TRUE,c2,1,TRUE,FALSE,-29,TRUE,"['Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only).', '* View URL\n* Click ""View Attachment as Diff""\n\n\nRequest url:\nURL\n\nThis makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS.', '--------------------------\n**Version**: unspecified\n**Severity**: major']",FALSE,0,"* View URL\n* Click ""View Attachment as Diff""\n\n\nRequest url:\nURL\n\nThis makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS.",OBSERVED BUG BEHAVIOR,, 15920,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",1360293600,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_description,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit * Click ""View Attachment as Diff"" Request url: https://bug-attachment.wikimedia.org/attachment.cgi?id=829 This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major","Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)./n/n* View URL * Click ""View Attachment as Diff"" Request url: URL This makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS. -------------------------- **Version**: unspecified **Severity**: major",Medium,50,1398336250,NA,resolved,TRUE,c2,1,TRUE,FALSE,-29,TRUE,"['Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only).', '* View URL\n* Click ""View Attachment as Diff""\n\n\nRequest url:\nURL\n\nThis makes it impossible to view diffs on https, and bugzilla is enforced to be on HTTPS.', '--------------------------\n**Version**: unspecified\n**Severity**: major']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 15921,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.",1398359452,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.","Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,34,TRUE,"['Ah, damn it, I should have re-read my comment 11 first before adding comment 13.', 'Sorry for my confusion.']",NA,0,"Ah, damn it, I should have re-read my comment 11 first before adding comment 13.",SOCIAL CONVERSATION,, 15921,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.",1398359452,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.","Ah, damn it, I should have re-read my comment 11 first before adding comment 13. Sorry for my confusion.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,34,TRUE,"['Ah, damn it, I should have re-read my comment 11 first before adding comment 13.', 'Sorry for my confusion.']",NA,0,Sorry for my confusion.,SOCIAL CONVERSATION,, 15922,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",1398157969,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://","(In reply to Ariel T. Glenn from comment #12) QUOTE QUOTE I set attachment_base from URL to URL but going to URL I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to URL which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,33,TRUE,"['(In reply to Ariel T. Glenn from comment #12)\nQUOTE\nQUOTE\n\nI set attachment_base from\n URL\nto\n URL\nbut going to \n URL\nI still get\n \nThe attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.', 'In order to view the attachment, you first have to download it.', 'Actions: View | Delete \n\nClicking on ""View"" I get to\n URL\nwhich offers to open locally in a text editor.', ""Not worse than before though, so I'll keep it as https://""]",NA,0,(In reply to Ariel T. Glenn from comment #12)\nQUOTE\nQUOTE\n\nI set attachment_base from\n URL\nto\n URL\nbut going to \n URL\nI still get\n \nThe attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.,OBSERVED BUG BEHAVIOR,, 15922,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",1398157969,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://","(In reply to Ariel T. Glenn from comment #12) QUOTE QUOTE I set attachment_base from URL to URL but going to URL I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to URL which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,33,TRUE,"['(In reply to Ariel T. Glenn from comment #12)\nQUOTE\nQUOTE\n\nI set attachment_base from\n URL\nto\n URL\nbut going to \n URL\nI still get\n \nThe attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.', 'In order to view the attachment, you first have to download it.', 'Actions: View | Delete \n\nClicking on ""View"" I get to\n URL\nwhich offers to open locally in a text editor.', ""Not worse than before though, so I'll keep it as https://""]",NA,0,"In order to view the attachment, you first have to download it.",BUG REPRODUCTION,, 15922,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",1398157969,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://","(In reply to Ariel T. Glenn from comment #12) QUOTE QUOTE I set attachment_base from URL to URL but going to URL I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to URL which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,33,TRUE,"['(In reply to Ariel T. Glenn from comment #12)\nQUOTE\nQUOTE\n\nI set attachment_base from\n URL\nto\n URL\nbut going to \n URL\nI still get\n \nThe attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.', 'In order to view the attachment, you first have to download it.', 'Actions: View | Delete \n\nClicking on ""View"" I get to\n URL\nwhich offers to open locally in a text editor.', ""Not worse than before though, so I'll keep it as https://""]",NA,0,"Actions: View | Delete \n\nClicking on ""View"" I get to\n URL\nwhich offers to open locally in a text editor.",BUG REPRODUCTION,, 15922,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",1398157969,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to Ariel T. Glenn from comment #12) > Can we try again with https in the attachment_base? (RT #2490 for the > grody details) I set attachment_base from http://bug-attachment.wikimedia.org/ to https://bug-attachment.wikimedia.org/ but going to https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to https://bugzilla.wikimedia.org/attachment.cgi?id=829 which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://","(In reply to Ariel T. Glenn from comment #12) QUOTE QUOTE I set attachment_base from URL to URL but going to URL I still get The attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator. In order to view the attachment, you first have to download it. Actions: View | Delete Clicking on ""View"" I get to URL which offers to open locally in a text editor. Not worse than before though, so I'll keep it as https://",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,33,TRUE,"['(In reply to Ariel T. Glenn from comment #12)\nQUOTE\nQUOTE\n\nI set attachment_base from\n URL\nto\n URL\nbut going to \n URL\nI still get\n \nThe attachment is not viewable in your browser due to security restrictions enabled by your Bugzilla administrator.', 'In order to view the attachment, you first have to download it.', 'Actions: View | Delete \n\nClicking on ""View"" I get to\n URL\nwhich offers to open locally in a text editor.', ""Not worse than before though, so I'll keep it as https://""]",NA,0,"Not worse than before though, so I'll keep it as https://",INVESTIGATION AND EXPLORATION,, 15923,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",1397742331,PHID-USER-jtxavgb3caz53o45csni,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,33,TRUE,"[""So view attachment works, but via a redirect to http, that can't be what we want."", 'Can we try again with https in the attachment_base?', '(rt #2490 for the grody details)']",NA,0,Can we try again with https in the attachment_base?,INVESTIGATION AND EXPLORATION,, 15923,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",1397742331,PHID-USER-jtxavgb3caz53o45csni,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,33,TRUE,"[""So view attachment works, but via a redirect to http, that can't be what we want."", 'Can we try again with https in the attachment_base?', '(rt #2490 for the grody details)']",NA,0,(rt #2490 for the grody details),ISSUE CONTENT MANAGEMENT,, 15923,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",1397742331,PHID-USER-jtxavgb3caz53o45csni,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)","So view attachment works, but via a redirect to http, that can't be what we want. Can we try again with https in the attachment_base? (rt #2490 for the grody details)",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,33,TRUE,"[""So view attachment works, but via a redirect to http, that can't be what we want."", 'Can we try again with https in the attachment_base?', '(rt #2490 for the grody details)']",NA,0,"So view attachment works, but via a redirect to http, that can't be what we want.",OBSERVED BUG BEHAVIOR,, 15924,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",1364148333,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.","(In reply to comment #0) QUOTE QUOTE That's not a diff (I should have realized that earlier). For URL or URL , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-23,TRUE,"[""(In reply to comment #0)\nQUOTE\nQUOTE\n\nThat's not a diff (I should have realized that earlier)."", 'For URL or URL , clicking ""View Attachment as Diff"" works fine.', ""I'm closing this as INVALID.""]",NA,0,"For URL or URL , clicking ""View Attachment as Diff"" works fine.",BUG REPRODUCTION,, 15924,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",1364148333,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.","(In reply to comment #0) QUOTE QUOTE That's not a diff (I should have realized that earlier). For URL or URL , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-23,TRUE,"[""(In reply to comment #0)\nQUOTE\nQUOTE\n\nThat's not a diff (I should have realized that earlier)."", 'For URL or URL , clicking ""View Attachment as Diff"" works fine.', ""I'm closing this as INVALID.""]",NA,0,(In reply to comment #0)\nQUOTE\nQUOTE\n\nThat's not a diff (I should have realized that earlier).,INVESTIGATION AND EXPLORATION,, 15924,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",1364148333,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" That's not a diff (I should have realized that earlier). For https://bugzilla.wikimedia.org/attachment.cgi?id=827&action=edit or https://bugzilla.wikimedia.org/attachment.cgi?id=11975&action=edit , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.","(In reply to comment #0) QUOTE QUOTE That's not a diff (I should have realized that earlier). For URL or URL , clicking ""View Attachment as Diff"" works fine. I'm closing this as INVALID.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-23,TRUE,"[""(In reply to comment #0)\nQUOTE\nQUOTE\n\nThat's not a diff (I should have realized that earlier)."", 'For URL or URL , clicking ""View Attachment as Diff"" works fine.', ""I'm closing this as INVALID.""]",NA,0,I'm closing this as INVALID.,ACTION ON ISSUE,, 15925,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",1363353908,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-24,TRUE,"[""<LpSolit> andre: the code and comments are correct...\n<LpSolit> if ($cgi->url_is_attachment_base($bug_id)) {\n<LpSolit> it will check if the URL is the one for the given attachment\n<LpSolit> and if it's not, then we know there is something wrong\n<LpSolit> which is what the comment says\n<LpSolit> # If we come here, this means that each bug has its own host\n<LpSolit> # for attachments, and that we are trying to view one attachment\n<LpSolit> # using another bug's host."", ""That's not desired."", ""<LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL""]",NA,0,"<LpSolit> andre: the code and comments are correct...\n<LpSolit> if ($cgi->url_is_attachment_base($bug_id)) {\n<LpSolit> it will check if the URL is the one for the given attachment\n<LpSolit> and if it's not, then we know there is something wrong\n<LpSolit> which is what the comment says\n<LpSolit> # If we come here, this means that each bug has its own host\n<LpSolit> # for attachments, and that we are trying to view one attachment\n<LpSolit> # using another bug's host.",INVESTIGATION AND EXPLORATION,, 15925,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",1363353908,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-24,TRUE,"[""<LpSolit> andre: the code and comments are correct...\n<LpSolit> if ($cgi->url_is_attachment_base($bug_id)) {\n<LpSolit> it will check if the URL is the one for the given attachment\n<LpSolit> and if it's not, then we know there is something wrong\n<LpSolit> which is what the comment says\n<LpSolit> # If we come here, this means that each bug has its own host\n<LpSolit> # for attachments, and that we are trying to view one attachment\n<LpSolit> # using another bug's host."", ""That's not desired."", ""<LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL""]",NA,0,That's not desired.,EXPECTED BEHAVIOR,, 15925,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",1363353908,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL","<LpSolit> andre: the code and comments are correct... <LpSolit> if ($cgi->url_is_attachment_base($bug_id)) { <LpSolit> it will check if the URL is the one for the given attachment <LpSolit> and if it's not, then we know there is something wrong <LpSolit> which is what the comment says <LpSolit> # If we come here, this means that each bug has its own host <LpSolit> # for attachments, and that we are trying to view one attachment <LpSolit> # using another bug's host. That's not desired. <LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-24,TRUE,"[""<LpSolit> andre: the code and comments are correct...\n<LpSolit> if ($cgi->url_is_attachment_base($bug_id)) {\n<LpSolit> it will check if the URL is the one for the given attachment\n<LpSolit> and if it's not, then we know there is something wrong\n<LpSolit> which is what the comment says\n<LpSolit> # If we come here, this means that each bug has its own host\n<LpSolit> # for attachments, and that we are trying to view one attachment\n<LpSolit> # using another bug's host."", ""That's not desired."", ""<LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL""]",NA,0,<LpSolit> you don't reach elsif ($cgi->url_is_attachment_base) if your are viewing attachments with the correct URL,INVESTIGATION AND EXPLORATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,"Looking at the code, the inline documentation comments confuse me.",SOCIAL CONVERSATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,"So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?",INVESTIGATION AND EXPLORATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,"Feels contradicting, but maybe I miss something obvious.",SOCIAL CONVERSATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?,INVESTIGATION AND EXPLORATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla.,INVESTIGATION AND EXPLORATION,, 15926,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",1362762954,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?","Looking at the code, the inline documentation comments confuse me. We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla. So attachment.cgi:293 states: elsif ($cgi->url_is_attachment_base) { # If we come here, this means that each bug has its own host for attachments which implies that attachment.cgi:264: if ($cgi->url_is_attachment_base($bug_id)) { would be executed if there is no %bugid% substring in attachment_base, right? But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says: # If we're passed an id, we only want one specific attachment base for a particular bug. Feels contradicting, but maybe I miss something obvious. Wild guesses: There are some calls for * do_ssl_redirect_if_required() * redirect_to_urlbase() in attachment.cgi which might be the reason for our issues?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-25,TRUE,"['Looking at the code, the inline documentation comments confuse me.', ""We don't use %bugid% in the attachment_base parameter of Wikimedia Bugzilla."", 'So attachment.cgi:293 states:\n elsif ($cgi->url_is_attachment_base) {\n # If we come here, this means that each bug has its own host for attachments\nwhich implies that attachment.cgi:264:\n if ($cgi->url_is_attachment_base($bug_id)) {\nwould be executed if there is no %bugid% substring in attachment_base, right?', ""But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug."", 'Feels contradicting, but maybe I miss something obvious.', 'Wild guesses: There are some calls for\n* do_ssl_redirect_if_required()\n* redirect_to_urlbase()\nin attachment.cgi which might be the reason for our issues?']",NA,0,"But in Bugzilla/CGI.pm:510's url_is_attachment_base() the comment says:\n# If we're passed an id, we only want one specific attachment base for a particular bug.",INVESTIGATION AND EXPLORATION,, 15927,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.",1362018458,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.","giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-26,TRUE,"['giving to default assignee for now and removing patch-in-gerrit keyword.', 'maybe someone with shell on kaulen can take a crack at it or I may look again at some point.']",NA,0,giving to default assignee for now and removing patch-in-gerrit keyword.,ACTION ON ISSUE,, 15927,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.",1362018458,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.","giving to default assignee for now and removing patch-in-gerrit keyword. maybe someone with shell on kaulen can take a crack at it or I may look again at some point.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-26,TRUE,"['giving to default assignee for now and removing patch-in-gerrit keyword.', 'maybe someone with shell on kaulen can take a crack at it or I may look again at some point.']",NA,0,maybe someone with shell on kaulen can take a crack at it or I may look again at some point.,CONTRIBUTION AND COMMITMENT,, 15928,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #4) > Want to try that again now that the apache conf change has been deployed? Done. Still doesn't work, same result as for http.",1361927162,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #4) > Want to try that again now that the apache conf change has been deployed? Done. Still doesn't work, same result as for http.","(In reply to comment #4) QUOTE Done. Still doesn't work, same result as for http.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-26,TRUE,"['(In reply to comment #4)\nQUOTE\n\nDone.', ""Still doesn't work, same result as for http.""]",NA,0,(In reply to comment #4)\nQUOTE\n\nDone.,TASK PROGRESS,, 15928,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #4) > Want to try that again now that the apache conf change has been deployed? Done. Still doesn't work, same result as for http.",1361927162,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #4) > Want to try that again now that the apache conf change has been deployed? Done. Still doesn't work, same result as for http.","(In reply to comment #4) QUOTE Done. Still doesn't work, same result as for http.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-26,TRUE,"['(In reply to comment #4)\nQUOTE\n\nDone.', ""Still doesn't work, same result as for http.""]",NA,0,"Still doesn't work, same result as for http.",BUG REPRODUCTION,, 15929,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #5) > The above urls still redirect to http://. I'm not sure what your point is. Comment #4 still holds.",1361907384,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #5) > The above urls still redirect to http://. I'm not sure what your point is. Comment #4 still holds.","(In reply to comment #5) QUOTE I'm not sure what your point is. Comment #4 still holds.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,"[""(In reply to comment #5)\nQUOTE\n\nI'm not sure what your point is."", 'Comment #4 still holds.']",NA,0,Comment #4 still holds.,SOCIAL CONVERSATION,, 15929,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #5) > The above urls still redirect to http://. I'm not sure what your point is. Comment #4 still holds.",1361907384,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #5) > The above urls still redirect to http://. I'm not sure what your point is. Comment #4 still holds.","(In reply to comment #5) QUOTE I'm not sure what your point is. Comment #4 still holds.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,"[""(In reply to comment #5)\nQUOTE\n\nI'm not sure what your point is."", 'Comment #4 still holds.']",NA,0,(In reply to comment #5)\nQUOTE\n\nI'm not sure what your point is.,SOCIAL CONVERSATION,, 15930,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" > > > Request url: > https://bug-attachment.wikimedia.org/attachment.cgi?id=829 > https://bug-attachment.wikimedia.org/attachment.cgi?id=827 The above urls still redirect to http://.",1361881826,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #0) > * View https://bugzilla.wikimedia.org/attachment.cgi?id=829&action=edit > * Click ""View Attachment as Diff"" > > > Request url: > https://bug-attachment.wikimedia.org/attachment.cgi?id=829 > https://bug-attachment.wikimedia.org/attachment.cgi?id=827 The above urls still redirect to http://.","(In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE URL The above urls still redirect to URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-27,TRUE,['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nURL\n\nThe above urls still redirect to URL'],NA,0,(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nURL\n\nThe above urls still redirect to URL,BUG REPRODUCTION,, 15931,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","(In reply to comment #1) > Value for attachment_base in Bugzilla is set to > http://bug-attachment.wikimedia.org/ > Changing it to > https://bug-attachment.wikimedia.org/ > won't fix this but the redirection would trigger [...] Want to try that again now that the apache conf change has been deployed?",1361848225,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"(In reply to comment #1) > Value for attachment_base in Bugzilla is set to > http://bug-attachment.wikimedia.org/ > Changing it to > https://bug-attachment.wikimedia.org/ > won't fix this but the redirection would trigger [...] Want to try that again now that the apache conf change has been deployed?","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE [...] Want to try that again now that the apache conf change has been deployed?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n[...]\n\nWant to try that again now that the apache conf change has been deployed?'],NA,0,(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n[...]\n\nWant to try that again now that the apache conf change has been deployed?,CONTRIBUTION AND COMMITMENT,, 15932,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","https://gerrit.wikimedia.org/r/#/c/49200/ RT #2490",1361186746,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"https://gerrit.wikimedia.org/r/#/c/49200/ RT #2490","URL RT #2490",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-28,TRUE,['URL\n\nRT #2490'],NA,0,URL\n\nRT #2490,ISSUE CONTENT MANAGEMENT,, 15933,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.",1360669160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.","Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Needs to fix apache configuration to not redirect this domain.', ""Though I can't find an entry for this redirect in the operations/apache-config.git repo.""]",NA,0,Needs to fix apache configuration to not redirect this domain.,INVESTIGATION AND EXPLORATION,, 15933,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.",1360669160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.","Needs to fix apache configuration to not redirect this domain. Though I can't find an entry for this redirect in the operations/apache-config.git repo.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Needs to fix apache configuration to not redirect this domain.', ""Though I can't find an entry for this redirect in the operations/apache-config.git repo.""]",NA,0,Though I can't find an entry for this redirect in the operations/apache-config.git repo.,INVESTIGATION AND EXPLORATION,, 15934,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",1360306685,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.","Confirming problem. Value for attachment_base in Bugzilla is set to URL Changing it to URL won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Confirming problem.', ""Value for attachment_base in Bugzilla is set to\n URL\nChanging it to\n URL \nwon't fix this but the redirection would trigger e.g."", '""the page isn\'t displaying properly"" in Firefox and still wouldn\'t enable ""View Attachment as Diff"".', 'Looks like nothing I could fix in Bugzilla itself.']",NA,0,Confirming problem.,SOCIAL CONVERSATION,, 15934,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",1360306685,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.","Confirming problem. Value for attachment_base in Bugzilla is set to URL Changing it to URL won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Confirming problem.', ""Value for attachment_base in Bugzilla is set to\n URL\nChanging it to\n URL \nwon't fix this but the redirection would trigger e.g."", '""the page isn\'t displaying properly"" in Firefox and still wouldn\'t enable ""View Attachment as Diff"".', 'Looks like nothing I could fix in Bugzilla itself.']",NA,0,"""the page isn\",NA,, 15934,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",1360306685,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.","Confirming problem. Value for attachment_base in Bugzilla is set to URL Changing it to URL won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Confirming problem.', ""Value for attachment_base in Bugzilla is set to\n URL\nChanging it to\n URL \nwon't fix this but the redirection would trigger e.g."", '""the page isn\'t displaying properly"" in Firefox and still wouldn\'t enable ""View Attachment as Diff"".', 'Looks like nothing I could fix in Bugzilla itself.']",NA,0,Value for attachment_base in Bugzilla is set to\n URL\nChanging it to\n URL \nwon't fix this but the redirection would trigger e.g.,INVESTIGATION AND EXPLORATION,, 15934,"Bugzilla: Diff viewer broken (bug-attachment.wikimedia.org/attachment.cgi is blocked, HTTP only)","Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",1360306685,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-4x6z4jjcyrncydazjosh,task_subcomment,"Confirming problem. Value for attachment_base in Bugzilla is set to http://bug-attachment.wikimedia.org/ Changing it to https://bug-attachment.wikimedia.org/ won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.","Confirming problem. Value for attachment_base in Bugzilla is set to URL Changing it to URL won't fix this but the redirection would trigger e.g. ""the page isn't displaying properly"" in Firefox and still wouldn't enable ""View Attachment as Diff"". Looks like nothing I could fix in Bugzilla itself.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-29,TRUE,"['Confirming problem.', ""Value for attachment_base in Bugzilla is set to\n URL\nChanging it to\n URL \nwon't fix this but the redirection would trigger e.g."", '""the page isn\'t displaying properly"" in Firefox and still wouldn\'t enable ""View Attachment as Diff"".', 'Looks like nothing I could fix in Bugzilla itself.']",NA,0, in Firefox and still wouldn\'t enable ,TESTING,, 16081,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601",1350678600,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-6niv2uripvn5aodbb53o,task_description,"HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601","HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' URL * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) QUOTE QUOTE QUOTE QUOTE QUOTE * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1392408741,NA,resolved,TRUE,c2,1,FALSE,FALSE,-45,TRUE,"[""HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set."", '$ curl -v -H \'User-Agent: iPhone\' URL\n* About to connect() to www.wikipedia.org port 80 (#0)\n* Trying 2620:0:861:ed1a::1...\n* connected\n* Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* HTTP 1.1 or later with persistent connection, pipelining supported\n< HTTP/1.1 504 Gateway Time-out\n< Server: nginx/0.7.65\n< Date: Fri, 19 Oct 2012 20:29:48 GMT\n< Content-Type: text/html\n< Content-Length: 183\n< Connection: keep-alive\n< \n<html>\n<head><title>504 Gateway Time-out</title></head>\n<body bgcolor=""white"">\n<center><h1>504 Gateway Time-out</h1></center>\n<hr><center>nginx/0.7.65</center>\n</body>\n</html>\n* Connection #0 to host www.wikipedia.org left intact\n* Closing connection #0\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,$ curl -v -H \,NA,, 16081,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601",1350678600,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-6niv2uripvn5aodbb53o,task_description,"HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601","HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' URL * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) QUOTE QUOTE QUOTE QUOTE QUOTE * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1392408741,NA,resolved,TRUE,c2,1,FALSE,FALSE,-45,TRUE,"[""HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set."", '$ curl -v -H \'User-Agent: iPhone\' URL\n* About to connect() to www.wikipedia.org port 80 (#0)\n* Trying 2620:0:861:ed1a::1...\n* connected\n* Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* HTTP 1.1 or later with persistent connection, pipelining supported\n< HTTP/1.1 504 Gateway Time-out\n< Server: nginx/0.7.65\n< Date: Fri, 19 Oct 2012 20:29:48 GMT\n< Content-Type: text/html\n< Content-Length: 183\n< Connection: keep-alive\n< \n<html>\n<head><title>504 Gateway Time-out</title></head>\n<body bgcolor=""white"">\n<center><h1>504 Gateway Time-out</h1></center>\n<hr><center>nginx/0.7.65</center>\n</body>\n</html>\n* Connection #0 to host www.wikipedia.org left intact\n* Closing connection #0\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0," URL\n* About to connect() to www.wikipedia.org port 80 (#0)\n* Trying 2620:0:861:ed1a::1...\n* connected\n* Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* HTTP 1.1 or later with persistent connection, pipelining supported\n< HTTP/1.1 504 Gateway Time-out\n< Server: nginx/0.7.65\n< Date: Fri, 19 Oct 2012 20:29:48 GMT\n< Content-Type: text/html\n< Content-Length: 183\n< Connection: keep-alive\n< \n<html>\n<head><title>504 Gateway Time-out</title></head>\n<body bgcolor=""white"">\n<center><h1>504 Gateway Time-out</h1></center>\n<hr><center>nginx/0.7.65</center>\n</body>\n</html>\n* Connection #0 to host www.wikipedia.org left intact\n* Closing connection #0\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL",BUG REPRODUCTION,, 16081,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601",1350678600,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-6niv2uripvn5aodbb53o,task_description,"HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' http://www.wikipedia.org/wiki/ * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) > GET /wiki/ HTTP/1.1 > Host: www.wikipedia.org > Accept: */* > User-Agent: iPhone > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36601","HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set./n/n$ curl -v -H 'User-Agent: iPhone' URL * About to connect() to www.wikipedia.org port 80 (#0) * Trying 2620:0:861:ed1a::1... * connected * Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0) QUOTE QUOTE QUOTE QUOTE QUOTE * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 504 Gateway Time-out < Server: nginx/0.7.65 < Date: Fri, 19 Oct 2012 20:29:48 GMT < Content-Type: text/html < Content-Length: 183 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor=""white""> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/0.7.65</center> </body> </html> * Connection #0 to host www.wikipedia.org left intact * Closing connection #0 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,1392408741,NA,resolved,TRUE,c2,1,FALSE,FALSE,-45,TRUE,"[""HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set."", '$ curl -v -H \'User-Agent: iPhone\' URL\n* About to connect() to www.wikipedia.org port 80 (#0)\n* Trying 2620:0:861:ed1a::1...\n* connected\n* Connected to www.wikipedia.org (2620:0:861:ed1a::1) port 80 (#0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* additional stuff not fine transfer.c:1037: 0 0\n* HTTP 1.1 or later with persistent connection, pipelining supported\n< HTTP/1.1 504 Gateway Time-out\n< Server: nginx/0.7.65\n< Date: Fri, 19 Oct 2012 20:29:48 GMT\n< Content-Type: text/html\n< Content-Length: 183\n< Connection: keep-alive\n< \n<html>\n<head><title>504 Gateway Time-out</title></head>\n<body bgcolor=""white"">\n<center><h1>504 Gateway Time-out</h1></center>\n<hr><center>nginx/0.7.65</center>\n</body>\n</html>\n* Connection #0 to host www.wikipedia.org left intact\n* Closing connection #0\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,HTTP/1.1 504 Gateway Time-out on URL when 'User-Agent: iPhone' is set.,OBSERVED BUG BEHAVIOR,, 16082,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,Can't reproduce; I get HTTP/1.1 301 Moved Permanently.,1392408741,PHID-USER-hxjysvdvogekpjub3nd3,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,Can't reproduce; I get HTTP/1.1 301 Moved Permanently.,Can't reproduce; I get HTTP/1.1 301 Moved Permanently.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,24,TRUE,"[""Can't reproduce; I get HTTP/1.1 301 Moved Permanently.""]",NA,0,Can't reproduce; I get HTTP/1.1 301 Moved Permanently.,BUG REPRODUCTION,, 16083,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",1350752719,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.","Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['Sorry it indeed was a syntax error.', ""When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL\n\nI do indeed get no response\n\nBy invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string."", 'I should have double checked my syntax to avoid confusion on the bug thread.', 'Sorry for that.']",NA,0,Sorry it indeed was a syntax error.,INVESTIGATION AND EXPLORATION,, 16083,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",1350752719,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.","Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['Sorry it indeed was a syntax error.', ""When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL\n\nI do indeed get no response\n\nBy invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string."", 'I should have double checked my syntax to avoid confusion on the bug thread.', 'Sorry for that.']",NA,0,I should have double checked my syntax to avoid confusion on the bug thread.,SOCIAL CONVERSATION,, 16083,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",1350752719,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.","Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['Sorry it indeed was a syntax error.', ""When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL\n\nI do indeed get no response\n\nBy invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string."", 'I should have double checked my syntax to avoid confusion on the bug thread.', 'Sorry for that.']",NA,0,Sorry for that.,SOCIAL CONVERSATION,, 16083,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",1350752719,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.","Sorry it indeed was a syntax error. When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL I do indeed get no response By invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string. I should have double checked my syntax to avoid confusion on the bug thread. Sorry for that.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['Sorry it indeed was a syntax error.', ""When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL\n\nI do indeed get no response\n\nBy invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string."", 'I should have double checked my syntax to avoid confusion on the bug thread.', 'Sorry for that.']",NA,0,"When I do curl -v -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL\n\nI do indeed get no response\n\nBy invalid I had merely hazarded a guess that the servers had not had the user agent 'iPhone' in mind but since the above user agent doesn't work either this is not it, I'm well aware they can be any arbitrary string.",BUG REPRODUCTION,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\,SOCIAL CONVERSATION,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,", ""And the value for that header can be any arbitrary string, so there",INVESTIGATION AND EXPLORATION,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,"s no response."", ",NA,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,invalid,NA,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,User Agent:,NA,, 16084,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",1350752265,PHID-USER-jnta3z3spxto3vbxdngm,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"(In reply to comment #2) > curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) > AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' > http://www.wikipedia.org/wiki/ works fine for me > > Is it because the user agent is invalid? I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3","(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE I don't know what are you referring to with ""invalid"". ""User Agent:"" is not valid. The correct header is ""User-Agent:"". And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that URL Even with your suggested value for user-agent, there's no response. You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end): GET /wiki/ HTTP/1.1 Host: www.wikipedia.org Accept: */* User-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don\'t know what are you referring to with ""invalid"".', '""User Agent:"" is not valid.', 'The correct header is ""User-Agent:"".', ""And the value for that header can be any arbitrary string, so there's apparently no valid/invalid value for that\n\nURL\n\nEven with your suggested value for user-agent, there's no response."", 'You can test this with any telnet client (preferably not the native telnet command of Windows, use PuTTY instead in RAW mode), connecting to www.wikipedia.org on port 80 and sending the following lines of text (with 2 empty newlines at the end):\n\nGET /wiki/ HTTP/1.1\nHost: www.wikipedia.org\nAccept: */*\nUser-Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3']",NA,0,User-Agent:,NA,, 16085,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,"curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ works fine for me Is it because the user agent is invalid?",1350751611,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,"curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' http://www.wikipedia.org/wiki/ works fine for me Is it because the user agent is invalid?","curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL works fine for me Is it because the user agent is invalid?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"[""curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL works fine for me\n\nIs it because the user agent is invalid?""]",NA,0,"curl -v H 'User Agent: Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3' URL works fine for me\n\nIs it because the user agent is invalid?",BUG REPRODUCTION,, 16086,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,1350693196,PHID-USER-qmantxp3p7omhisp3qgq,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['I can confirm this happening with not just iPhone but also Android.', ""This issue is upstream of Mobile Front end as MF doesn't serve this URL""]",NA,0,I can confirm this happening with not just iPhone but also Android.,BUG REPRODUCTION,, 16086,HTTP/1.1 504 Gateway Time-out on http://www.wikipedia.org/wiki/ when 'User-Agent: iPhone' is set,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,1350693196,PHID-USER-qmantxp3p7omhisp3qgq,PHID-TASK-6niv2uripvn5aodbb53o,task_subcomment,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,I can confirm this happening with not just iPhone but also Android. This issue is upstream of Mobile Front end as MF doesn't serve this URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-45,TRUE,"['I can confirm this happening with not just iPhone but also Android.', ""This issue is upstream of Mobile Front end as MF doesn't serve this URL""]",NA,0,This issue is upstream of Mobile Front end as MF doesn't serve this URL,INVESTIGATION AND EXPLORATION,, 16195,https://m.mediawiki.org/w/index.php uses the wrong certificate,"Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",1342376580,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-3vb45zykveazkgcvuiol,task_description,"https://m.mediawiki.org/w/index.php uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal","URL uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of URL (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",Medium,50,1361358978,NA,resolved,TRUE,c2,1,FALSE,FALSE,-59,TRUE,"['URL uses the wrong certificate.', 'Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org .', 'Should probably use the certificate of URL (*.mediawiki.org)\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,URL uses the wrong certificate.,INVESTIGATION AND EXPLORATION,, 16195,https://m.mediawiki.org/w/index.php uses the wrong certificate,"Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",1342376580,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-3vb45zykveazkgcvuiol,task_description,"https://m.mediawiki.org/w/index.php uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal","URL uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of URL (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",Medium,50,1361358978,NA,resolved,TRUE,c2,1,FALSE,FALSE,-59,TRUE,"['URL uses the wrong certificate.', 'Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org .', 'Should probably use the certificate of URL (*.mediawiki.org)\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,"Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org .",INVESTIGATION AND EXPLORATION,, 16195,https://m.mediawiki.org/w/index.php uses the wrong certificate,"Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",1342376580,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-3vb45zykveazkgcvuiol,task_description,"https://m.mediawiki.org/w/index.php uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of https://www.mediawiki.org/ (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal","URL uses the wrong certificate./n/nSends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org . Should probably use the certificate of URL (*.mediawiki.org) -------------------------- **Version**: wmf-deployment **Severity**: normal",Medium,50,1361358978,NA,resolved,TRUE,c2,1,FALSE,FALSE,-59,TRUE,"['URL uses the wrong certificate.', 'Sends a certificate for *.m.wikipedia.org , *.wikipedia.org , wikipedia.org .', 'Should probably use the certificate of URL (*.mediawiki.org)\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,Should probably use the certificate of URL (*.mediawiki.org)\n\n--------------------------\n**Version**: wmf-deployment\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 16196,https://m.mediawiki.org/w/index.php uses the wrong certificate,"**inbox** wrote: %%%*** This bug has been marked as a duplicate of bug 34788 ***%%%",1361358978,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-3vb45zykveazkgcvuiol,task_subcomment,"**inbox** wrote: %%%*** This bug has been marked as a duplicate of bug 34788 ***%%%","**inbox** wrote: %%%*** This bug has been marked as a duplicate of bug 34788 ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,['**inbox** wrote:\n\n\n\n%%%*** This bug has been marked as a duplicate of bug 34788 ***%%%'],NA,0,**inbox** wrote:\n\n\n\n%%%*** This bug has been marked as a duplicate of bug 34788 ***%%%,ACTION ON ISSUE,, 16197,https://m.mediawiki.org/w/index.php uses the wrong certificate,Dupe of bug 34788?,1350100746,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-3vb45zykveazkgcvuiol,task_subcomment,Dupe of bug 34788?,Dupe of bug 34788?,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-46,TRUE,['Dupe of bug 34788?'],NA,0,Dupe of bug 34788?,ISSUE CONTENT MANAGEMENT,, 16592,MWHttpRequest::execute doesn't return a value,"According to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",1340116560,PHID-USER-vlni4mhyozor7ghqnfkl,PHID-TASK-vc3crewu6hac463o42lb,task_description,"MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal","MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1534976308,PHID-USER-y7auzjvgmrrms6atggom,resolved,TRUE,c2,1,FALSE,FALSE,-63,TRUE,"[""MWHttpRequest::execute doesn't return a value."", 'According to documentation execute() should return a value, which it does not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"According to documentation execute() should return a value, which it does not.",INVESTIGATION AND EXPLORATION,, 16592,MWHttpRequest::execute doesn't return a value,"According to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",1340116560,PHID-USER-vlni4mhyozor7ghqnfkl,PHID-TASK-vc3crewu6hac463o42lb,task_description,"MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal","MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1534976308,PHID-USER-y7auzjvgmrrms6atggom,resolved,TRUE,c2,1,FALSE,FALSE,-63,TRUE,"[""MWHttpRequest::execute doesn't return a value."", 'According to documentation execute() should return a value, which it does not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 16592,MWHttpRequest::execute doesn't return a value,"According to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",1340116560,PHID-USER-vlni4mhyozor7ghqnfkl,PHID-TASK-vc3crewu6hac463o42lb,task_description,"MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal","MWHttpRequest::execute doesn't return a value./n/nAccording to documentation execute() should return a value, which it does not. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1534976308,PHID-USER-y7auzjvgmrrms6atggom,resolved,TRUE,c2,1,FALSE,FALSE,-63,TRUE,"[""MWHttpRequest::execute doesn't return a value."", 'According to documentation execute() should return a value, which it does not.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,MWHttpRequest::execute doesn't return a value.,OBSERVED BUG BEHAVIOR,, 16593,MWHttpRequest::execute doesn't return a value,Closing this task. Revive if needed.,1534976308,PHID-USER-y7auzjvgmrrms6atggom,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,Closing this task. Revive if needed.,Closing this task. Revive if needed.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,260,TRUE,"['Closing this task.', 'Revive if needed.']",NA,0,Closing this task.,ACTION ON ISSUE,, 16593,MWHttpRequest::execute doesn't return a value,Closing this task. Revive if needed.,1534976308,PHID-USER-y7auzjvgmrrms6atggom,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,Closing this task. Revive if needed.,Closing this task. Revive if needed.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,260,TRUE,"['Closing this task.', 'Revive if needed.']",NA,0,Revive if needed.,ACTION ON ISSUE ,, 16594,MWHttpRequest::execute doesn't return a value,This is pretty old-ish<73><68><EFBFBD>,1492114077,PHID-USER-vlni4mhyozor7ghqnfkl,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,This is pretty old-ish<73><68><EFBFBD>,This is pretty old-ish<73><68><EFBFBD>,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,189,TRUE,['This is pretty old-ish<73><68><EFBFBD>'],NA,0,This is pretty old-ish<73><68><EFBFBD>,SOCIAL CONVERSATION,, 16595,MWHttpRequest::execute doesn't return a value,Removing #easy as per comments in Gerrit.,1476799091,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,Removing #easy as per comments in Gerrit.,Removing #easy as per comments in Gerrit.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,163,TRUE,['Removing #easy as per comments in Gerrit.'],NA,0,Removing #easy as per comments in Gerrit.,ACTION ON ISSUE ,, 16596,MWHttpRequest::execute doesn't return a value,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712",1381331785,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712","Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for CODE Reason: Abandoning this change. Feel free to revive if there is reason to. GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Change 47712 abandoned by Siebrand:\n(bug 37713) Fix documentation for CODE\n\nReason:\nAbandoning this change.', 'Feel free to revive if there is reason to.', 'GERRIT_URL']",NA,0,Change 47712 abandoned by Siebrand:\n(bug 37713) Fix documentation for CODE\n\nReason:\nAbandoning this change.,TASK PROGRESS,, 16596,MWHttpRequest::execute doesn't return a value,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712",1381331785,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712","Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for CODE Reason: Abandoning this change. Feel free to revive if there is reason to. GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Change 47712 abandoned by Siebrand:\n(bug 37713) Fix documentation for CODE\n\nReason:\nAbandoning this change.', 'Feel free to revive if there is reason to.', 'GERRIT_URL']",NA,0,Feel free to revive if there is reason to.,ACTION ON ISSUE ,, 16596,MWHttpRequest::execute doesn't return a value,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712",1381331785,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for `MWHttpRequest::execute` Reason: Abandoning this change. Feel free to revive if there is reason to. https://gerrit.wikimedia.org/r/47712","Change 47712 abandoned by Siebrand: (bug 37713) Fix documentation for CODE Reason: Abandoning this change. Feel free to revive if there is reason to. GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,"['Change 47712 abandoned by Siebrand:\n(bug 37713) Fix documentation for CODE\n\nReason:\nAbandoning this change.', 'Feel free to revive if there is reason to.', 'GERRIT_URL']",NA,0,GERRIT_URL,TASK PROGRESS,, 16597,MWHttpRequest::execute doesn't return a value,Patch in Gerrit needs rework...,1374662855,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,Patch in Gerrit needs rework...,Patch in Gerrit needs rework...,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-5,TRUE,['Patch in Gerrit needs rework...'],NA,0,Patch in Gerrit needs rework...,SOLUTION DISCUSSION ,, 16598,MWHttpRequest::execute doesn't return a value,"I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?",1361511064,PHID-USER-w6tinhtsh44tn3tgzjtw,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?","I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,"[""I think execute() should be made abstract and its code moved to some other method 'setup'?"", 'or at least make it protected?']",NA,0,or at least make it protected?,FUTURE PLANS,, 16598,MWHttpRequest::execute doesn't return a value,"I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?",1361511064,PHID-USER-w6tinhtsh44tn3tgzjtw,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?","I think execute() should be made abstract and its code moved to some other method 'setup'? or at least make it protected?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-27,TRUE,"[""I think execute() should be made abstract and its code moved to some other method 'setup'?"", 'or at least make it protected?']",NA,0,I think execute() should be made abstract and its code moved to some other method 'setup'?,SOLUTION DISCUSSION ,, 16599,MWHttpRequest::execute doesn't return a value,seems like this has been worked upon https://gerrit.wikimedia.org/r/#/c/47712/,1360162794,PHID-USER-w6tinhtsh44tn3tgzjtw,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,seems like this has been worked upon https://gerrit.wikimedia.org/r/#/c/47712/,seems like this has been worked upon URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-29,TRUE,['seems like this has been worked upon URL'],NA,0,seems like this has been worked upon URL,INVESTIGATION AND EXPLORATION,, 16600,MWHttpRequest::execute doesn't return a value,We should change the documentation to remove the @return then. No need to make it return anything.,1340753567,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,We should change the documentation to remove the @return then. No need to make it return anything.,We should change the documentation to remove theSCREEN_NAME then. No need to make it return anything.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-62,TRUE,"['We should change the documentation to remove theSCREEN_NAME then.', 'No need to make it return anything.']",NA,0,We should change the documentation to remove theSCREEN_NAME then.,SOLUTION DISCUSSION,, 16600,MWHttpRequest::execute doesn't return a value,We should change the documentation to remove the @return then. No need to make it return anything.,1340753567,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,We should change the documentation to remove the @return then. No need to make it return anything.,We should change the documentation to remove theSCREEN_NAME then. No need to make it return anything.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-62,TRUE,"['We should change the documentation to remove theSCREEN_NAME then.', 'No need to make it return anything.']",NA,0,No need to make it return anything.,SOLUTION DISCUSSION,, 16601,MWHttpRequest::execute doesn't return a value,"(In reply to comment #0) > According to documentation execute() should return a value, which it does not. Technically, the function in that class isn't documented ;)",1340121979,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-vc3crewu6hac463o42lb,task_subcomment,"(In reply to comment #0) > According to documentation execute() should return a value, which it does not. Technically, the function in that class isn't documented ;)","(In reply to comment #0) QUOTE Technically, the function in that class isn't documented ;)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-63,TRUE,"[""(In reply to comment #0)\nQUOTE\n\nTechnically, the function in that class isn't documented ;)""]",NA,0,"(In reply to comment #0)\nQUOTE\n\nTechnically, the function in that class isn't documented ;)",INVESTIGATION AND EXPLORATION,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,$this->method should be string case agnostic in MwHttpRequest classes.,EXPECTED BEHAVIOR,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Fix forthcoming.,CONTRIBUTION AND COMMITMENT,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly.",OBSERVED BUG BEHAVIOR,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing.,EXPECTED BEHAVIOR,, 16693,$this->method should be string case agnostic in MwHttpRequest classes,"Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",1334958120,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_description,"$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal","$this->method should be string case agnostic in MwHttpRequest classes./n/nCurrently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly. This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing. Replacing lines like } elseif ( $this->method == 'POST' ) { with } elseif ( strtoupper( $this->method ) == 'POST' ) { should do the trick and be more developer friendly. Fix forthcoming. -------------------------- **Version**: unspecified **Severity**: normal",Needs Triage,90,1335018793,NA,resolved,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['$this->method should be string case agnostic in MwHttpRequest classes.', ""Currently, when creating MwHttpRequest objects, the 'method' option/parameter must match case exactly."", ""This seems unnecessary and caused me to bang my head against the wall for a while trying to figure out why my requests weren't POSTing."", ""Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly."", 'Fix forthcoming.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,Replacing lines like\n} elseif ( $this->method == 'POST' ) {\nwith\n} elseif ( strtoupper( $this->method ) == 'POST' ) {\nshould do the trick and be more developer friendly.,SOLUTION DISCUSSION,, 16694,$this->method should be string case agnostic in MwHttpRequest classes,Fixed in c5493,1335018793,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,Fixed in c5493,Fixed in c5493,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,['Fixed in c5493'],NA,0,Fixed in c5493,TASK PROGRESS,, 16695,$this->method should be string case agnostic in MwHttpRequest classes,"Fixed in commit 1122ca5f8750a7e23e3f00ad7c03a19ef25f4c17 with Change-Id: Ic20e1b99dcb56b8a11cea50293ba44022e564de9 (https://gerrit.wikimedia.org/r/#change,5493)",1334960391,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"Fixed in commit 1122ca5f8750a7e23e3f00ad7c03a19ef25f4c17 with Change-Id: Ic20e1b99dcb56b8a11cea50293ba44022e564de9 (https://gerrit.wikimedia.org/r/#change,5493)",Fixed in commit 1122ca5f8750a7e23e3f00ad7c03a19ef25f4c17 with Change-Id: Ic20e1b99dcb56b8a11cea50293ba44022e564de9 (URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,['Fixed in commit 1122ca5f8750a7e23e3f00ad7c03a19ef25f4c17 with Change-Id: Ic20e1b99dcb56b8a11cea50293ba44022e564de9 (URL'],NA,0,Fixed in commit 1122ca5f8750a7e23e3f00ad7c03a19ef25f4c17 with Change-Id: Ic20e1b99dcb56b8a11cea50293ba44022e564de9 (URL,TASK PROGRESS,, 16696,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",1334959349,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.","(In reply to comment #5) QUOTE QUOTE QUOTE I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest."", ""Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar)."", ""I'll play around a bit with the HTTP class though and see what I can/can't do."", 'Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.', 'Defensive programming ftw.']",NA,0,"Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.",EXPECTED BEHAVIOR,, 16696,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",1334959349,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.","(In reply to comment #5) QUOTE QUOTE QUOTE I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest."", ""Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar)."", ""I'll play around a bit with the HTTP class though and see what I can/can't do."", 'Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.', 'Defensive programming ftw.']",NA,0,Defensive programming ftw.,SOCIAL CONVERSATION,, 16696,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",1334959349,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.","(In reply to comment #5) QUOTE QUOTE QUOTE I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest."", ""Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar)."", ""I'll play around a bit with the HTTP class though and see what I can/can't do."", 'Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.', 'Defensive programming ftw.']",NA,0,(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest.,INVESTIGATION AND EXPLORATION,, 16696,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",1334959349,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.","(In reply to comment #5) QUOTE QUOTE QUOTE I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest."", ""Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar)."", ""I'll play around a bit with the HTTP class though and see what I can/can't do."", 'Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.', 'Defensive programming ftw.']",NA,0,"Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar).",SOLUTION USAGE,, 16696,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",1334959349,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #5) > The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if > MWHttpRequest original intention was for it to be called directly or not, but > I'd do it through HTTP. I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.","(In reply to comment #5) QUOTE QUOTE QUOTE I see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest. Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar). I'll play around a bit with the HTTP class though and see what I can/can't do. Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase. Defensive programming ftw.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nI see what you mean - however the HTTP class doesn't let me control the cookieJar in MWHttpRequest."", ""Basically, I've put together a very lightweight (currently) single-purpose MW Api client in a MW extension which can post to remote wikis, which means I need to be able to persist login information (hence my need for the cookieJar)."", ""I'll play around a bit with the HTTP class though and see what I can/can't do."", 'Regardless, if the MWHttpRequest is looking for $this->method in all uppercase, it probably should ensure that values are getting set in all uppercase.', 'Defensive programming ftw.']",NA,0,I'll play around a bit with the HTTP class though and see what I can/can't do.,CONTRIBUTION AND COMMITMENT,, 16697,$this->method should be string case agnostic in MwHttpRequest classes,"The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.",1334959033,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.","The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['The HTTP class seems to be a gatekeeper for MWHttpRequest.', ""I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.""]",NA,0,The HTTP class seems to be a gatekeeper for MWHttpRequest.,INVESTIGATION AND EXPLORATION,, 16697,$this->method should be string case agnostic in MwHttpRequest classes,"The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.",1334959033,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.","The HTTP class seems to be a gatekeeper for MWHttpRequest. I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['The HTTP class seems to be a gatekeeper for MWHttpRequest.', ""I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.""]",NA,0,"I don't know if MWHttpRequest original intention was for it to be called directly or not, but I'd do it through HTTP.",SOLUTION USAGE,, 16698,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #3) > HTTP::request is doing a strtoupper on the method. Are you calling > MWHttpRequest::factory directly? Yes. Should I not be?",1334958797,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #3) > HTTP::request is doing a strtoupper on the method. Are you calling > MWHttpRequest::factory directly? Yes. Should I not be?","(In reply to comment #3) QUOTE QUOTE Yes. Should I not be?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nYes.', 'Should I not be?']",NA,0,(In reply to comment #3)\nQUOTE\nQUOTE\n\nYes.,SOCIAL CONVERSATION,, 16698,$this->method should be string case agnostic in MwHttpRequest classes,"(In reply to comment #3) > HTTP::request is doing a strtoupper on the method. Are you calling > MWHttpRequest::factory directly? Yes. Should I not be?",1334958797,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"(In reply to comment #3) > HTTP::request is doing a strtoupper on the method. Are you calling > MWHttpRequest::factory directly? Yes. Should I not be?","(In reply to comment #3) QUOTE QUOTE Yes. Should I not be?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nYes.', 'Should I not be?']",NA,0,Should I not be?,SOCIAL CONVERSATION,, 16699,$this->method should be string case agnostic in MwHttpRequest classes,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,1334958537,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['HTTP::request is doing a strtoupper on the method.', 'Are you calling MWHttpRequest::factory directly?']",NA,0,HTTP::request is doing a strtoupper on the method.,INVESTIGATION AND EXPLORATION,, 16699,$this->method should be string case agnostic in MwHttpRequest classes,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,1334958537,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,HTTP::request is doing a strtoupper on the method. Are you calling MWHttpRequest::factory directly?,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['HTTP::request is doing a strtoupper on the method.', 'Are you calling MWHttpRequest::factory directly?']",NA,0,Are you calling MWHttpRequest::factory directly?,INVESTIGATION AND EXPLORATION,, 16700,$this->method should be string case agnostic in MwHttpRequest classes,"Alternatively, $this->method could benefit from a setter function that automatically strtoupper's the param",1334958334,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"Alternatively, $this->method could benefit from a setter function that automatically strtoupper's the param","Alternatively, $this->method could benefit from a setter function that automatically strtoupper's the param",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"[""Alternatively, $this->method could benefit from a setter function that automatically strtoupper's the param""]",NA,0,"Alternatively, $this->method could benefit from a setter function that automatically strtoupper's the param",SOLUTION DISCUSSION ,, 16701,$this->method should be string case agnostic in MwHttpRequest classes,"Also, just for reference, there is precedence for this already in HttpFunctions.php: if ( strtoupper( $this->method ) == ""HEAD"" ) { $this->headersOnly = true; }",1334958254,PHID-USER-jh2oguhshocanixqvlfk,PHID-TASK-tv2vswa4obhqhgbwjeuy,task_subcomment,"Also, just for reference, there is precedence for this already in HttpFunctions.php: if ( strtoupper( $this->method ) == ""HEAD"" ) { $this->headersOnly = true; }","Also, just for reference, there is precedence for this already in HttpFunctions.php: if ( strtoupper( $this->method ) == ""HEAD"" ) { $this->headersOnly = true; }",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['Also, just for reference, there is precedence for this already in HttpFunctions.php:\n\t\tif ( strtoupper( $this->method ) == ""HEAD"" ) {\n\t\t\t$this->headersOnly = true;\n\t\t}']",NA,0,"Also, just for reference, there is precedence for this already in HttpFunctions.php:\n\t\tif ( strtoupper( $this->method ) == ""HEAD"" ) {\n\t\t\t$this->headersOnly = true;\n\t\t}",SOLUTION DISCUSSION ,, 17045,No way to do logins without user surrendering their password to software,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",1331645520,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_description,"No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348","No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1416907981,PHID-USER-ppytiem7rcsbnstfsrvq,declined,TRUE,c2,1,TRUE,TRUE,-77,TRUE,"['No way to do logins without user surrendering their password to software.', 'There is currently no way to login to SUL on production.', ""Regular login which asks for password isn't possible because of restrictions set by wmf."", 'This blocks the development of app, until any kind of login is enabled by wmf operation team.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,No way to do logins without user surrendering their password to software.,OBSERVED BUG BEHAVIOR,, 17045,No way to do logins without user surrendering their password to software,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",1331645520,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_description,"No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348","No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1416907981,PHID-USER-ppytiem7rcsbnstfsrvq,declined,TRUE,c2,1,TRUE,TRUE,-77,TRUE,"['No way to do logins without user surrendering their password to software.', 'There is currently no way to login to SUL on production.', ""Regular login which asks for password isn't possible because of restrictions set by wmf."", 'This blocks the development of app, until any kind of login is enabled by wmf operation team.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,There is currently no way to login to SUL on production.,OBSERVED BUG BEHAVIOR,, 17045,No way to do logins without user surrendering their password to software,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",1331645520,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_description,"No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348","No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1416907981,PHID-USER-ppytiem7rcsbnstfsrvq,declined,TRUE,c2,1,TRUE,TRUE,-77,TRUE,"['No way to do logins without user surrendering their password to software.', 'There is currently no way to login to SUL on production.', ""Regular login which asks for password isn't possible because of restrictions set by wmf."", 'This blocks the development of app, until any kind of login is enabled by wmf operation team.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"This blocks the development of app, until any kind of login is enabled by wmf operation team.",OBSERVED BUG BEHAVIOR,, 17045,No way to do logins without user surrendering their password to software,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",1331645520,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_description,"No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348","No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1416907981,PHID-USER-ppytiem7rcsbnstfsrvq,declined,TRUE,c2,1,TRUE,TRUE,-77,TRUE,"['No way to do logins without user surrendering their password to software.', 'There is currently no way to login to SUL on production.', ""Regular login which asks for password isn't possible because of restrictions set by wmf."", 'This blocks the development of app, until any kind of login is enabled by wmf operation team.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 17045,No way to do logins without user surrendering their password to software,"There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348",1331645520,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_description,"No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=30348","No way to do logins without user surrendering their password to software./n/nThere is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",Medium,50,1416907981,PHID-USER-ppytiem7rcsbnstfsrvq,declined,TRUE,c2,1,TRUE,TRUE,-77,TRUE,"['No way to do logins without user surrendering their password to software.', 'There is currently no way to login to SUL on production.', ""Regular login which asks for password isn't possible because of restrictions set by wmf."", 'This blocks the development of app, until any kind of login is enabled by wmf operation team.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,Regular login which asks for password isn't possible because of restrictions set by wmf.,OBSERVED BUG BEHAVIOR,, 17046,No way to do logins without user surrendering their password to software,"BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported",1416910649,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported","BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,64,TRUE,"[""BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported""]",NA,0,"BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported",INVESTIGATION AND EXPLORATION,, 17047,No way to do logins without user surrendering their password to software,"this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.",1416910556,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.","this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,64,TRUE,"['this is irrelevant, whole huggle-wa project is closed now.', ""bug is closed as it's no longer valid.""]",NA,0,"this is irrelevant, whole huggle-wa project is closed now.",ISSUE CONTENT MANAGEMENT,, 17047,No way to do logins without user surrendering their password to software,"this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.",1416910556,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.","this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,64,TRUE,"['this is irrelevant, whole huggle-wa project is closed now.', ""bug is closed as it's no longer valid.""]",NA,0,bug is closed as it's no longer valid.,ACTION ON ISSUE ,, 17048,No way to do logins without user surrendering their password to software,">>! In T37199#400227, @Petrb wrote: > ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work ""for app it doesn't work"" which app doesnt it work for? Is there a ticket open for why oauth doesnt work? ",1416909680,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,">>! In T37199#400227, @Petrb wrote: > ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work ""for app it doesn't work"" which app doesnt it work for? Is there a ticket open for why oauth doesnt work? ","QUOTE QUOTE ""for app it doesn't work"" which app doesnt it work for? Is there a ticket open for why oauth doesnt work? ",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,64,TRUE,"['QUOTE\nQUOTE\n\n""for app it doesn\'t work"" which app doesnt it work for?', 'Is there a ticket open for why oauth doesnt work?']",NA,0,"QUOTE\nQUOTE\n\n""for app it doesn\",NA,, 17049,No way to do logins without user surrendering their password to software,"ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work",1379754742,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work","ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"[""ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work""]",NA,0,"ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work",INVESTIGATION AND EXPLORATION,, 17050,No way to do logins without user surrendering their password to software,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.",1376789843,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.","(In reply to comment #13) QUOTE QUOTE QUOTE Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <URL OAuth is going into testing on Monday, August 19.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nPossible?', 'Sure.', ""But it's unlikely to be implemented on Wikimedia wikis."", 'According to <URL OAuth is going into testing on Monday, August 19.']",NA,0,(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nPossible?,SOCIAL CONVERSATION,, 17050,No way to do logins without user surrendering their password to software,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.",1376789843,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.","(In reply to comment #13) QUOTE QUOTE QUOTE Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <URL OAuth is going into testing on Monday, August 19.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nPossible?', 'Sure.', ""But it's unlikely to be implemented on Wikimedia wikis."", 'According to <URL OAuth is going into testing on Monday, August 19.']",NA,0,Sure.,SOCIAL CONVERSATION,, 17050,No way to do logins without user surrendering their password to software,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.",1376789843,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.","(In reply to comment #13) QUOTE QUOTE QUOTE Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <URL OAuth is going into testing on Monday, August 19.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nPossible?', 'Sure.', ""But it's unlikely to be implemented on Wikimedia wikis."", 'According to <URL OAuth is going into testing on Monday, August 19.']",NA,0,"According to <URL OAuth is going into testing on Monday, August 19.",FUTURE PLANS,, 17050,No way to do logins without user surrendering their password to software,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.",1376789843,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #13) > Is it possible to provide users with an edit token that is visible via > preferences (like the watchlist token), and is expired frequently; e.g. daily > reset, with an age of 24 hrs after first use of the token. Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html>, OAuth is going into testing on Monday, August 19.","(In reply to comment #13) QUOTE QUOTE QUOTE Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to <URL OAuth is going into testing on Monday, August 19.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['(In reply to comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nPossible?', 'Sure.', ""But it's unlikely to be implemented on Wikimedia wikis."", 'According to <URL OAuth is going into testing on Monday, August 19.']",NA,0,But it's unlikely to be implemented on Wikimedia wikis.,POTENTIAL NEW ISSUES AND REQUESTS,, 17051,No way to do logins without user surrendering their password to software,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",1376788537,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.","Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g.', 'daily reset, with an age of 24 hrs after first use of the token.', 'Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.']",NA,0,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g.",SOLUTION DISCUSSION,, 17051,No way to do logins without user surrendering their password to software,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",1376788537,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.","Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g.', 'daily reset, with an age of 24 hrs after first use of the token.', 'Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.']",NA,0,"daily reset, with an age of 24 hrs after first use of the token.",SOLUTION DISCUSSION,, 17051,No way to do logins without user surrendering their password to software,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",1376788537,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.","Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token. Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",NA,NA,NA,NA,NA,TRUE,c2,2,TRUE,NA,-2,TRUE,"['Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g.', 'daily reset, with an age of 24 hrs after first use of the token.', 'Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.']",NA,0,"Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.",SOLUTION DISCUSSION,, 17052,No way to do logins without user surrendering their password to software,The session cookie wouldn't work. It's different domains and separate clusters.,1347489787,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,The session cookie wouldn't work. It's different domains and separate clusters.,The session cookie wouldn't work. It's different domains and separate clusters.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"[""The session cookie wouldn't work."", ""It's different domains and separate clusters.""]",NA,0,The session cookie wouldn't work.,SOLUTION DISCUSSION,, 17052,No way to do logins without user surrendering their password to software,The session cookie wouldn't work. It's different domains and separate clusters.,1347489787,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,The session cookie wouldn't work. It's different domains and separate clusters.,The session cookie wouldn't work. It's different domains and separate clusters.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"[""The session cookie wouldn't work."", ""It's different domains and separate clusters.""]",NA,0,It's different domains and separate clusters.,INVESTIGATION AND EXPLORATION,, 17053,No way to do logins without user surrendering their password to software,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",1347488647,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.","The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['The session cookie.', 'The app could still impersonate the user, but it wouldn\'t have the ""permanent"" password.', 'Yes, getting OAuth (or equivalent protocol) up, would be the right solution.']",NA,0,The session cookie.,SOLUTION DISCUSSION ,, 17053,No way to do logins without user surrendering their password to software,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",1347488647,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.","The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['The session cookie.', 'The app could still impersonate the user, but it wouldn\'t have the ""permanent"" password.', 'Yes, getting OAuth (or equivalent protocol) up, would be the right solution.']",NA,0,"The app could still impersonate the user, but it wouldn\",SOLUTION USAGE,, 17053,No way to do logins without user surrendering their password to software,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",1347488647,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.","The session cookie. The app could still impersonate the user, but it wouldn't have the ""permanent"" password. Yes, getting OAuth (or equivalent protocol) up, would be the right solution.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['The session cookie.', 'The app could still impersonate the user, but it wouldn\'t have the ""permanent"" password.', 'Yes, getting OAuth (or equivalent protocol) up, would be the right solution.']",NA,0,permanent,NA,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,Which cookies?,INVESTIGATION AND EXPLORATION,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,"Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.",SOLUTION DISCUSSION ,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,Maybe bring this up on the list again?,CONTRIBUTION AND COMMITMENT,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,OAuth is blocking a number of things in labs.,POTENTIAL NEW ISSUES AND REQUESTS,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,I don't see much alternative here other than OAuth.,SOLUTION DISCUSSION ,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,A web version of huggle would need to act on a user's behalf.,SOLUTION DISCUSSION,, 17054,No way to do logins without user surrendering their password to software,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",1347431015,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.","Which cookies? I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth. I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-50,TRUE,"['Which cookies?', ""I don't see much alternative here other than OAuth."", ""A web version of huggle would need to act on a user's behalf."", 'Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.', ""I don't really have much say on OAuth priority in MediaWiki."", 'Maybe bring this up on the list again?', 'OAuth is blocking a number of things in labs.']",NA,0,I don't really have much say on OAuth priority in MediaWiki.,SOCIAL CONVERSATION,, 17055,No way to do logins without user surrendering their password to software,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",1347402508,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.","An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-51,TRUE,"['An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...).', 'I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots.', 'It would be nice here, too.']",NA,0,An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...).,SOLUTION DISCUSSION ,, 17055,No way to do logins without user surrendering their password to software,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",1347402508,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.","An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-51,TRUE,"['An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...).', 'I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots.', 'It would be nice here, too.']",NA,0,"I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots.",SOLUTION DISCUSSION,, 17055,No way to do logins without user surrendering their password to software,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",1347402508,PHID-USER-izojihzr4ja3jsgzn5wv,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.","An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...). I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-51,TRUE,"['An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...).', 'I have long have the idea of allowing ""restricted logins"", where you can only use a few rights, precisely for handing out to bots.', 'It would be nice here, too.']",NA,0,"It would be nice here, too.",MOTIVATION,, 17056,No way to do logins without user surrendering their password to software,"**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)",1347402242,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)","**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-51,TRUE,"['**mmovchin** wrote:\n\nRyan: Something new with this?', 'We need your input to continue to work :)']",NA,0,**mmovchin** wrote:\n\nRyan: Something new with this?,SOCIAL CONVERSATION,, 17056,No way to do logins without user surrendering their password to software,"**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)",1347402242,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)","**mmovchin** wrote: Ryan: Something new with this? We need your input to continue to work :)",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-51,TRUE,"['**mmovchin** wrote:\n\nRyan: Something new with this?', 'We need your input to continue to work :)']",NA,0,We need your input to continue to work :),CONTRIBUTION AND COMMITMENT,, 17057,No way to do logins without user surrendering their password to software,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",1331821050,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)","Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-76,TRUE,"['Ryan:\n\nis there going to be a work-around for this or we need to wait until oauth is implemented?', 'I suppose that in that case we would need to stop for, maybe several years with this.', ""I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer."", '(My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)']",NA,0,Ryan:\n\nis there going to be a work-around for this or we need to wait until oauth is implemented?,INVESTIGATION AND EXPLORATION,, 17057,No way to do logins without user surrendering their password to software,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",1331821050,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)","Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-76,TRUE,"['Ryan:\n\nis there going to be a work-around for this or we need to wait until oauth is implemented?', 'I suppose that in that case we would need to stop for, maybe several years with this.', ""I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer."", '(My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)']",NA,0,"I suppose that in that case we would need to stop for, maybe several years with this.",FUTURE PLANS,, 17057,No way to do logins without user surrendering their password to software,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",1331821050,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)","Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-76,TRUE,"['Ryan:\n\nis there going to be a work-around for this or we need to wait until oauth is implemented?', 'I suppose that in that case we would need to stop for, maybe several years with this.', ""I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer."", '(My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)']",NA,0,"(My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",CONTRIBUTION AND COMMITMENT,, 17057,No way to do logins without user surrendering their password to software,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",1331821050,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)","Ryan: is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-76,TRUE,"['Ryan:\n\nis there going to be a work-around for this or we need to wait until oauth is implemented?', 'I suppose that in that case we would need to stop for, maybe several years with this.', ""I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer."", '(My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)']",NA,0,"I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer.",FUTURE PLANS,, 17058,No way to do logins without user surrendering their password to software,"(In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. thread here: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59502",1331774322,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. thread here: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59502","(In reply to comment #3) QUOTE QUOTE QUOTE thread here: URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-76,TRUE,['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nthread here: URL'],NA,0,(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nthread here: URL,ISSUE CONTENT MANAGEMENT,, 17059,No way to do logins without user surrendering their password to software,"yes but that is allowed by wmf, while doing it on server is not",1331667950,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"yes but that is allowed by wmf, while doing it on server is not","yes but that is allowed by wmf, while doing it on server is not",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-77,TRUE,"['yes but that is allowed by wmf, while doing it on server is not']",NA,0,"yes but that is allowed by wmf, while doing it on server is not",INVESTIGATION AND EXPLORATION,, 17060,No way to do logins without user surrendering their password to software,"(In reply to comment #2) > Ryan Lane is going to discuss some alternative options which are possible, > however until then the development is kind of blocked, so I created this ticket > so other devs of huggle wa can see the reason (In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...",1331661018,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #2) > Ryan Lane is going to discuss some alternative options which are possible, > however until then the development is kind of blocked, so I created this ticket > so other devs of huggle wa can see the reason (In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...","(In reply to comment #2) QUOTE QUOTE QUOTE (In reply to comment #3) QUOTE QUOTE QUOTE Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-77,TRUE,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nEssentially that's no different to how the Windows app works - You still enter your username and password into the application."", ""Just for the web app, you're giving a remote server your details too...""]",NA,0,(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nEssentially that's no different to how the Windows app works - You still enter your username and password into the application.,EXPECTED BEHAVIOR,, 17060,No way to do logins without user surrendering their password to software,"(In reply to comment #2) > Ryan Lane is going to discuss some alternative options which are possible, > however until then the development is kind of blocked, so I created this ticket > so other devs of huggle wa can see the reason (In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...",1331661018,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #2) > Ryan Lane is going to discuss some alternative options which are possible, > however until then the development is kind of blocked, so I created this ticket > so other devs of huggle wa can see the reason (In reply to comment #3) > What he's saying is that the web version of huggle needs to log users in as > themselves, which means it needs to ask for their username/password. Obviously > this sucks a little, but there's no alternative because we don't support OAuth. Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...","(In reply to comment #2) QUOTE QUOTE QUOTE (In reply to comment #3) QUOTE QUOTE QUOTE Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-77,TRUE,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nEssentially that's no different to how the Windows app works - You still enter your username and password into the application."", ""Just for the web app, you're giving a remote server your details too...""]",NA,0,"Just for the web app, you're giving a remote server your details too...",INVESTIGATION AND EXPLORATION,, 17061,No way to do logins without user surrendering their password to software,"What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.",1331660724,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.","What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-77,TRUE,"[""What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password."", ""Obviously this sucks a little, but there's no alternative because we don't support OAuth.""]",NA,0,"What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password.",MOTIVATION,, 17061,No way to do logins without user surrendering their password to software,"What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.",1331660724,PHID-USER-xs3vxsmgivmm2tuyxsrb,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.","What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-77,TRUE,"[""What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password."", ""Obviously this sucks a little, but there's no alternative because we don't support OAuth.""]",NA,0,"Obviously this sucks a little, but there's no alternative because we don't support OAuth.",SOLUTION DISCUSSION,, 17062,No way to do logins without user surrendering their password to software,"Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason",1331660199,PHID-USER-ppytiem7rcsbnstfsrvq,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason","Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-77,TRUE,"['Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason']",NA,0,"Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason",ISSUE CONTENT MANAGEMENT,, 17063,No way to do logins without user surrendering their password to software,"(In reply to comment #0) > There is currently no way to login to SUL on production. Regular login which > asks for password isn't possible because of restrictions set by wmf. This > blocks the development of app, until any kind of login is enabled by wmf > operation team. Eh, what?",1331659506,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-hygsocxkypuho4yqoprw,task_subcomment,"(In reply to comment #0) > There is currently no way to login to SUL on production. Regular login which > asks for password isn't possible because of restrictions set by wmf. This > blocks the development of app, until any kind of login is enabled by wmf > operation team. Eh, what?","(In reply to comment #0) QUOTE QUOTE QUOTE QUOTE Eh, what?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-77,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nEh, what?']",NA,0,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nEh, what?",SOCIAL CONVERSATION,, 17158,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",1327700760,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_description,"SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098","SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: URL",Medium,50,1329004026,NA,resolved,TRUE,c2,1,FALSE,FALSE,-83,TRUE,"['SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.', ""I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also."", 'When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.', 'Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.', 'When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.,OBSERVED BUG BEHAVIOR,, 17158,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",1327700760,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_description,"SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098","SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: URL",Medium,50,1329004026,NA,resolved,TRUE,c2,1,FALSE,FALSE,-83,TRUE,"['SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.', ""I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also."", 'When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.', 'Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.', 'When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.",OBSERVED BUG BEHAVIOR,, 17158,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",1327700760,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_description,"SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098","SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: URL",Medium,50,1329004026,NA,resolved,TRUE,c2,1,FALSE,FALSE,-83,TRUE,"['SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.', ""I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also."", 'When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.', 'Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.', 'When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.",SOLUTION DISCUSSION,, 17158,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",1327700760,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_description,"SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098","SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: URL",Medium,50,1329004026,NA,resolved,TRUE,c2,1,FALSE,FALSE,-83,TRUE,"['SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.', ""I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also."", 'When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.', 'Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.', 'When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL",OBSERVED BUG BEHAVIOR,, 17158,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098",1327700760,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_description,"SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57098","SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page./n/nI'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page -------------------------- **Version**: 1.20.x **Severity**: normal **See Also**: URL",Medium,50,1329004026,NA,resolved,TRUE,c2,1,FALSE,FALSE,-83,TRUE,"['SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page.', ""I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also."", 'When users have requested a temporary password through Special:PasswortReset and \n\n- come back to the wiki \n- and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page.', 'Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment.', 'When doing a passwort reset (enter the temporary password and twice a different, new password) on\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\nthe Create Account/Login portlet has incorrectly\n\n/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset\n\ninstead of \n\n/index.php?title=Special:UserLogin&returnto=Main+Page\n\n--------------------------\n**Version**: 1.20.x\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also.",BUG REPRODUCTION,, 17159,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I tried your patch, this appears to work as expected and described. great. fixed in r111270",1329004026,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"I tried your patch, this appears to work as expected and described. great. fixed in r111270","I tried your patch, this appears to work as expected and described. great. fixed in r111270",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['I tried your patch, this appears to work as expected and described.', 'great.', 'fixed in r111270']",NA,0,"I tried your patch, this appears to work as expected and described.",TASK PROGRESS,, 17159,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I tried your patch, this appears to work as expected and described. great. fixed in r111270",1329004026,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"I tried your patch, this appears to work as expected and described. great. fixed in r111270","I tried your patch, this appears to work as expected and described. great. fixed in r111270",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['I tried your patch, this appears to work as expected and described.', 'great.', 'fixed in r111270']",NA,0,great.,SOCIAL CONVERSATION,, 17159,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"I tried your patch, this appears to work as expected and described. great. fixed in r111270",1329004026,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"I tried your patch, this appears to work as expected and described. great. fixed in r111270","I tried your patch, this appears to work as expected and described. great. fixed in r111270",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['I tried your patch, this appears to work as expected and described.', 'great.', 'fixed in r111270']",NA,0,fixed in r111270,TASK PROGRESS,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.",SOCIAL CONVERSATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.,BUG REPRODUCTION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,Modification of SpecialUserLogin to check if the returntitle is PasswordReset.,INVESTIGATION AND EXPLORATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"If yes, make the returnto empty.",SOLUTION DISCUSSION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,Similar solution exits for the UserLogout page.,SOLUTION DISCUSSION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.",INVESTIGATION AND EXPLORATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.",INVESTIGATION AND EXPLORATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,2,NA,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,Second solution is to modify the SkinTemplate to modify the login url itself.,SOLUTION DISCUSSION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.,SOLUTION DISCUSSION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.",CONTRIBUTION AND COMMITMENT,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,Thanks in advance.,SOCIAL CONVERSATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"Regards,\nAashish\n\n**Attached**: {F8804}",SOCIAL CONVERSATION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied.",SOLUTION DISCUSSION,, 17160,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",1328988236,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}","**ashishmittal.mail** wrote: changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish **Attached**: {F8804}",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nchanges to SpecialUserLogin to return to Main_Page after a password change\n\nHello,\n\nThanks for the detailed explanation.', 'I reproduced the second scenario and was able to figure out the following solutions for it:\n\n1.', 'Modification of SpecialUserLogin to check if the returntitle is PasswordReset.', 'If yes, make the returnto empty.', ""The code snippet is:\n\n# Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change\n\t\tif( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) {\n\t\t\t$this->mReturnTo = '';\n\t\t\t$this->mReturnToQuery = '';\n\t\t}\n\nIn this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied."", 'Similar solution exits for the UserLogout page.', 'In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout.', 'Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page.', '2.', 'Second solution is to modify the SkinTemplate to modify the login url itself.', ""In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page."", 'This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in.', 'I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine.', 'Thanks in advance.', 'Regards,\nAashish\n\n**Attached**: {F8804}']",NA,0,"In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page.",INVESTIGATION AND EXPLORATION,, 17161,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",1328966488,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to URL - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to URL - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI think, I need to give a detailed analysis.', 'Allow me to use some ""bold"" words to point to the differences.', 'There is _no_ problem for this case I:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- you go to your mail client\n- you click on the link in your mail - the link goes to URL \n- you come to the newly rendered Main page \n- where you now click onto login \n- enter your temporary password, and 2x the new one\n= Okay\n\nThe problem is visible in this scenario case II:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."")\n- you goto to your mail\n- you DO NOT click on the link in your mail (the link goes to URL\n- you switch to your still-opened browser window with the unchanged page of step (X)\n- where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) )\n- enter your temporary password, and 2x the new one\n\nProblem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.']",NA,0,"(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI think, I need to give a detailed analysis.",SOCIAL CONVERSATION,, 17161,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",1328966488,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to URL - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to URL - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI think, I need to give a detailed analysis.', 'Allow me to use some ""bold"" words to point to the differences.', 'There is _no_ problem for this case I:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- you go to your mail client\n- you click on the link in your mail - the link goes to URL \n- you come to the newly rendered Main page \n- where you now click onto login \n- enter your temporary password, and 2x the new one\n= Okay\n\nThe problem is visible in this scenario case II:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."")\n- you goto to your mail\n- you DO NOT click on the link in your mail (the link goes to URL\n- you switch to your still-opened browser window with the unchanged page of step (X)\n- where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) )\n- enter your temporary password, and 2x the new one\n\nProblem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.']",NA,0,"Allow me to use some ""bold"" words to point to the differences.",SOCIAL CONVERSATION,, 17161,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",1328966488,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.","(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I think, I need to give a detailed analysis. Allow me to use some ""bold"" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to URL - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to URL - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI think, I need to give a detailed analysis.', 'Allow me to use some ""bold"" words to point to the differences.', 'There is _no_ problem for this case I:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- you go to your mail client\n- you click on the link in your mail - the link goes to URL \n- you come to the newly rendered Main page \n- where you now click onto login \n- enter your temporary password, and 2x the new one\n= Okay\n\nThe problem is visible in this scenario case II:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."")\n- you goto to your mail\n- you DO NOT click on the link in your mail (the link goes to URL\n- you switch to your still-opened browser window with the unchanged page of step (X)\n- where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) )\n- enter your temporary password, and 2x the new one\n\nProblem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.']",NA,0,"There is _no_ problem for this case I:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- you go to your mail client\n- you click on the link in your mail - the link goes to URL \n- you come to the newly rendered Main page \n- where you now click onto login \n- enter your temporary password, and 2x the new one\n= Okay\n\nThe problem is visible in this scenario case II:\n\n- you or someone else has triggered to have the password ""reset"" mail sent to you from the Special:PasswordReset page\n- (X) you LEAVE THIS browser page as it stands (saying something like ""a temporary password has been successfully mailed to ..."")\n- you goto to your mail\n- you DO NOT click on the link in your mail (the link goes to URL\n- you switch to your still-opened browser window with the unchanged page of step (X)\n- where you now click onto login link (THIS LINK HAS THE WRONG returnto URL because the page was not rendered again, still stands at (X) )\n- enter your temporary password, and 2x the new one\n\nProblem: now your are again at ""Special:PasswordReset"" , which is correct behaviour of the Wiki software, but not what a user wants.",INVESTIGATION AND EXPLORATION,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,"**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.",CONTRIBUTION AND COMMITMENT,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,"Thanks,\nAashish",SOCIAL CONVERSATION,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,"As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest).",INVESTIGATION AND EXPLORATION,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,"Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again.",BUG REPRODUCTION,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,"Hence in this case, we might need to explicitly set the parameter to the 'main-page'.",SOLUTION DISCUSSION,, 17162,SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",1328964834,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-tag5y25e6jgf6tfreibs,task_subcomment,"**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish","**ashishmittal.mail** wrote: Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-81,TRUE,"['**ashishmittal.mail** wrote:\n\nHello,\n\nI would like to solve this bug.', ""As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest)."", ""Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again."", ""Hence in this case, we might need to explicitly set the parameter to the 'main-page'."", ""Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide."", 'Thanks,\nAashish']",NA,0,Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto']\n\nKindly suggest if I am on the right track and guide.,SOLUTION DISCUSSION,, 17355,Mandate only-SSL for accounts with access to private information,"Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898",1317645180,PHID-USER-p5svl2m3pqm6jjgznnhz,PHID-TASK-oqffx6o3iwadtddsapew,task_description,"Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898","Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL URL URL",Medium,50,1440147353,PHID-USER-arjqb24x4oae7awzpfp6,resolved,TRUE,c2,1,FALSE,FALSE,-100,TRUE,"['Mandate only-SSL for accounts with access to private information.', 'Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL\nURL\nURL']",FALSE,0,Mandate only-SSL for accounts with access to private information.,EXPECTED BEHAVIOR,, 17355,Mandate only-SSL for accounts with access to private information,"Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898",1317645180,PHID-USER-p5svl2m3pqm6jjgznnhz,PHID-TASK-oqffx6o3iwadtddsapew,task_description,"Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898","Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL URL URL",Medium,50,1440147353,PHID-USER-arjqb24x4oae7awzpfp6,resolved,TRUE,c2,1,FALSE,FALSE,-100,TRUE,"['Mandate only-SSL for accounts with access to private information.', 'Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL\nURL\nURL']",FALSE,0,"Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.",MOTIVATION,, 17355,Mandate only-SSL for accounts with access to private information,"Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898",1317645180,PHID-USER-p5svl2m3pqm6jjgznnhz,PHID-TASK-oqffx6o3iwadtddsapew,task_description,"Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 https://bugzilla.wikimedia.org/show_bug.cgi?id=29898","Mandate only-SSL for accounts with access to private information./n/nMaking it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL URL URL",Medium,50,1440147353,PHID-USER-arjqb24x4oae7awzpfp6,resolved,TRUE,c2,1,FALSE,FALSE,-100,TRUE,"['Mandate only-SSL for accounts with access to private information.', 'Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL\nURL\nURL']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL\nURL\nURL,OBSERVED BUG BEHAVIOR,, 17356,Mandate only-SSL for accounts with access to private information,Resolved since HTTPS has been enforced for everyone.,1440147353,PHID-USER-arjqb24x4oae7awzpfp6,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,Resolved since HTTPS has been enforced for everyone.,Resolved since HTTPS has been enforced for everyone.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,103,TRUE,['Resolved since HTTPS has been enforced for everyone.'],NA,0,Resolved since HTTPS has been enforced for everyone.,ACTION ON ISSUE,, 17357,Mandate only-SSL for accounts with access to private information,"(In reply to comment #9) > All HTTP cookies have a ""Secure"" attribute that determines whether the > browser > will send them over HTTP or not. So, in other words, the actual protocol > under > which the cookie was sent is irrelevant, it's the Secure flag on the cookie > that matters. > > When you log in using HTTPS in MediaWiki, almost every cookie is set to > Secure > so that it only goes over HTTPS. However, if you look in User::setCookies, > you'll see that the forceHTTPS cookie is explicitly set without the Secure > attribute so that it'll be visible regardless of protocol. That's a crystal clear explanation, thank you!",1359744054,PHID-USER-irahijhmu2pqmwuewejz,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"(In reply to comment #9) > All HTTP cookies have a ""Secure"" attribute that determines whether the > browser > will send them over HTTP or not. So, in other words, the actual protocol > under > which the cookie was sent is irrelevant, it's the Secure flag on the cookie > that matters. > > When you log in using HTTPS in MediaWiki, almost every cookie is set to > Secure > so that it only goes over HTTPS. However, if you look in User::setCookies, > you'll see that the forceHTTPS cookie is explicitly set without the Secure > attribute so that it'll be visible regardless of protocol. That's a crystal clear explanation, thank you!","(In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE That's a crystal clear explanation, thank you!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"[""(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's a crystal clear explanation, thank you!""]",NA,0,"(In reply to comment #9)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's a crystal clear explanation, thank you!",SOCIAL CONVERSATION,, 17358,Mandate only-SSL for accounts with access to private information,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",1359743335,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.","All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"['All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not.', ""So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters."", 'When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS.', ""However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.""]",NA,0,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not.",INVESTIGATION AND EXPLORATION,, 17358,Mandate only-SSL for accounts with access to private information,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",1359743335,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.","All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"['All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not.', ""So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters."", 'When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS.', ""However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.""]",NA,0,"When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS.",INVESTIGATION AND EXPLORATION,, 17358,Mandate only-SSL for accounts with access to private information,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",1359743335,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.","All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"['All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not.', ""So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters."", 'When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS.', ""However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.""]",NA,0,"So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters.",INVESTIGATION AND EXPLORATION,, 17358,Mandate only-SSL for accounts with access to private information,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",1359743335,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.","All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters. When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"['All HTTP cookies have a ""Secure"" attribute that determines whether the browser will send them over HTTP or not.', ""So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters."", 'When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS.', ""However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.""]",NA,0,"However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.",INVESTIGATION AND EXPLORATION,, 17359,Mandate only-SSL for accounts with access to private information,"Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?",1359741909,PHID-USER-irahijhmu2pqmwuewejz,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?","Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"[""Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS?"", ""Isn't it already too late to redirect him to HTTPS?""]",NA,0,"Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS?",INVESTIGATION AND EXPLORATION,, 17359,Mandate only-SSL for accounts with access to private information,"Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?",1359741909,PHID-USER-irahijhmu2pqmwuewejz,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?","Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"[""Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS?"", ""Isn't it already too late to redirect him to HTTPS?""]",NA,0,Isn't it already too late to redirect him to HTTPS?,SOLUTION DISCUSSION,, 17360,Mandate only-SSL for accounts with access to private information,https://gerrit.wikimedia.org/r/47089,1359741252,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,https://gerrit.wikimedia.org/r/47089,GERRIT_URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,['GERRIT_URL'],NA,0,GERRIT_URL,TASK PROGRESS,, 17361,Mandate only-SSL for accounts with access to private information,"(In reply to comment #5) > And now that all that code is in place, I think it should be trivial in the > login to say if a user is a member of a particular group, force stickHTTPS to > true. What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.",1359739120,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"(In reply to comment #5) > And now that all that code is in place, I think it should be trivial in the > login to say if a user is a member of a particular group, force stickHTTPS to > true. What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.","(In reply to comment #5) QUOTE QUOTE QUOTE What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-30,TRUE,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about global groups?', 'Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.']",NA,0,(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about global groups?,INVESTIGATION AND EXPLORATION,, 17361,Mandate only-SSL for accounts with access to private information,"(In reply to comment #5) > And now that all that code is in place, I think it should be trivial in the > login to say if a user is a member of a particular group, force stickHTTPS to > true. What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.",1359739120,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"(In reply to comment #5) > And now that all that code is in place, I think it should be trivial in the > login to say if a user is a member of a particular group, force stickHTTPS to > true. What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.","(In reply to comment #5) QUOTE QUOTE QUOTE What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-30,TRUE,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about global groups?', 'Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.']",NA,0,"Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.",INVESTIGATION AND EXPLORATION,, 17362,Mandate only-SSL for accounts with access to private information,"And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.",1359738539,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.","And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-30,TRUE,"['And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.']",NA,0,"And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.",SOLUTION DISCUSSION,, 17363,Mandate only-SSL for accounts with access to private information,"FYI, here's the bug for secure login for all users: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380",1359738125,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"FYI, here's the bug for secure login for all users: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380","FYI, here's the bug for secure login for all users: URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-30,TRUE,"[""FYI, here's the bug for secure login for all users: URL""]",NA,0,"FYI, here's the bug for secure login for all users: URL",ISSUE CONTENT MANAGEMENT,, 17364,Mandate only-SSL for accounts with access to private information,"Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.",1317661965,PHID-USER-p5svl2m3pqm6jjgznnhz,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.","Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-100,TRUE,"['Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins.', ""But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.""]",NA,0,"Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins.",OBSERVED BUG BEHAVIOR,, 17364,Mandate only-SSL for accounts with access to private information,"Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.",1317661965,PHID-USER-p5svl2m3pqm6jjgznnhz,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.","Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-100,TRUE,"['Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins.', ""But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.""]",NA,0,"But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.",SOLUTION DISCUSSION,, 17365,Mandate only-SSL for accounts with access to private information,"(In reply to comment #1) > If we can require SSL for some logins, it would be irresponsible not to require > SSL for *all* logins. What about requiring HTTPS for all logins, and HTTPS for all further pages of special users?",1317658792,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"(In reply to comment #1) > If we can require SSL for some logins, it would be irresponsible not to require > SSL for *all* logins. What about requiring HTTPS for all logins, and HTTPS for all further pages of special users?","(In reply to comment #1) QUOTE QUOTE What about requiring HTTPS for all logins, and HTTPS for all further pages of special users?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-100,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nWhat about requiring HTTPS for all logins, and HTTPS for all further pages of special users?']",NA,0,"(In reply to comment #1)\nQUOTE\nQUOTE\n\nWhat about requiring HTTPS for all logins, and HTTPS for all further pages of special users?",SOLUTION DISCUSSION,, 17366,Mandate only-SSL for accounts with access to private information,"If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.",1317658435,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-oqffx6o3iwadtddsapew,task_subcomment,"If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.","If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-100,TRUE,"['If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.']",NA,0,"If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.",POTENTIAL NEW ISSUES AND REQUESTS,, 17381,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link","When login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",1316535900,PHID-USER-s3mqwzhzumlh2w5g756e,PHID-TASK-5lxu426whlsnvndt5675,task_description,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal","Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",Medium,50,1345034912,NA,resolved,TRUE,c2,0,FALSE,FALSE,-102,TRUE,"['Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link.', 'When login-in with $wgSecureLogin=true set, all logins return to the Main Page.', ""Cause:\nWhen $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters."", '--------------------------\n**Version**: 1.17.x\n**Severity**: normal']",TRUE,0,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link.",OBSERVED BUG BEHAVIOR,, 17381,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link","When login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",1316535900,PHID-USER-s3mqwzhzumlh2w5g756e,PHID-TASK-5lxu426whlsnvndt5675,task_description,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal","Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",Medium,50,1345034912,NA,resolved,TRUE,c2,0,FALSE,FALSE,-102,TRUE,"['Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link.', 'When login-in with $wgSecureLogin=true set, all logins return to the Main Page.', ""Cause:\nWhen $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters."", '--------------------------\n**Version**: 1.17.x\n**Severity**: normal']",TRUE,0,"When login-in with $wgSecureLogin=true set, all logins return to the Main Page.",OBSERVED BUG BEHAVIOR,, 17381,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link","When login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",1316535900,PHID-USER-s3mqwzhzumlh2w5g756e,PHID-TASK-5lxu426whlsnvndt5675,task_description,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal","Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",Medium,50,1345034912,NA,resolved,TRUE,c2,0,FALSE,FALSE,-102,TRUE,"['Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link.', 'When login-in with $wgSecureLogin=true set, all logins return to the Main Page.', ""Cause:\nWhen $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters."", '--------------------------\n**Version**: 1.17.x\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: 1.17.x\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17381,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link","When login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",1316535900,PHID-USER-s3mqwzhzumlh2w5g756e,PHID-TASK-5lxu426whlsnvndt5675,task_description,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal","Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link./n/nWhen login-in with $wgSecureLogin=true set, all logins return to the Main Page. Cause: When $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters. -------------------------- **Version**: 1.17.x **Severity**: normal",Medium,50,1345034912,NA,resolved,TRUE,c2,0,FALSE,FALSE,-102,TRUE,"['Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link.', 'When login-in with $wgSecureLogin=true set, all logins return to the Main Page.', ""Cause:\nWhen $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters."", '--------------------------\n**Version**: 1.17.x\n**Severity**: normal']",TRUE,0,Cause:\nWhen $wgSecureLogin=true is set the $login_url['href'] (of SkinTemplate.php) does not set the returnto parameters.,INVESTIGATION AND EXPLORATION,, 17382,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link",patch merged.,1345034912,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-5lxu426whlsnvndt5675,task_subcomment,patch merged.,patch merged.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-54,TRUE,['patch merged.'],NA,0,patch merged.,TASK PROGRESS,, 17383,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link",https://gerrit.wikimedia.org/r/18493,1344625237,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-5lxu426whlsnvndt5675,task_subcomment,https://gerrit.wikimedia.org/r/18493,GERRIT_URL,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-55,TRUE,['GERRIT_URL'],NA,0,GERRIT_URL,TASK PROGRESS,, 17384,"Enabling $wgSecureLogin does not set returnto on ""Log in / create account"" link",reported per CR on r75585,1316626394,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-5lxu426whlsnvndt5675,task_subcomment,reported per CR on r75585,reported per CR on r75585,NA,NA,NA,NA,NA,TRUE,c2,0,TRUE,NA,-101,TRUE,['reported per CR on r75585'],NA,0,reported per CR on r75585,ISSUE CONTENT MANAGEMENT,, 17567,server prototype.wikimedia.org has no https,"Updating a mediawiki file @enWP, and the call of javascript only works for http:// call Working http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js Not working https://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js -------------------------- **Version**: unspecified **Severity**: normal",1323415320,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-s6esjv72iihkh6eqj5rd,task_description,"server prototype.wikimedia.org has no https./n/nUpdating a mediawiki file @enWP, and the call of javascript only works for http:// call Working http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js Not working https://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js -------------------------- **Version**: unspecified **Severity**: normal","server prototype.wikimedia.org has no https./n/nUpdating a mediawiki fileSCREEN_NAME, and the call of javascript only works for http:// call Working URL Not working URL -------------------------- **Version**: unspecified **Severity**: normal",Lowest,10,1323556952,NA,declined,TRUE,c2,1,FALSE,FALSE,-90,TRUE,"['server prototype.wikimedia.org has no https.', 'Updating a mediawiki fileSCREEN_NAME, and the call of javascript only works for http:// call\n\n\nWorking\nURL\n\nNot working\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,server prototype.wikimedia.org has no https.,OBSERVED BUG BEHAVIOR,, 17567,server prototype.wikimedia.org has no https,"Updating a mediawiki file @enWP, and the call of javascript only works for http:// call Working http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js Not working https://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js -------------------------- **Version**: unspecified **Severity**: normal",1323415320,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-s6esjv72iihkh6eqj5rd,task_description,"server prototype.wikimedia.org has no https./n/nUpdating a mediawiki file @enWP, and the call of javascript only works for http:// call Working http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js Not working https://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/mediaWiki.js -------------------------- **Version**: unspecified **Severity**: normal","server prototype.wikimedia.org has no https./n/nUpdating a mediawiki fileSCREEN_NAME, and the call of javascript only works for http:// call Working URL Not working URL -------------------------- **Version**: unspecified **Severity**: normal",Lowest,10,1323556952,NA,declined,TRUE,c2,1,FALSE,FALSE,-90,TRUE,"['server prototype.wikimedia.org has no https.', 'Updating a mediawiki fileSCREEN_NAME, and the call of javascript only works for http:// call\n\n\nWorking\nURL\n\nNot working\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Updating a mediawiki fileSCREEN_NAME, and the call of javascript only works for http:// call\n\n\nWorking\nURL\n\nNot working\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal",OBSERVED BUG BEHAVIOR,, 17568,server prototype.wikimedia.org has no https,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,1323520272,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-s6esjv72iihkh6eqj5rd,task_subcomment,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['I am happy with this being marked as WONT FIX.', 'I was just following general instructions for where no https.']",NA,0,I am happy with this being marked as WONT FIX.,ACTION ON ISSUE,, 17568,server prototype.wikimedia.org has no https,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,1323520272,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-s6esjv72iihkh6eqj5rd,task_subcomment,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,I am happy with this being marked as WONT FIX. I was just following general instructions for where no https.,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['I am happy with this being marked as WONT FIX.', 'I was just following general instructions for where no https.']",NA,0,I was just following general instructions for where no https.,INVESTIGATION AND EXPLORATION,, 17569,server prototype.wikimedia.org has no https,"In theory you should not load anything from Prototype, on the assumption it may disappear at any moment.",1323434141,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-s6esjv72iihkh6eqj5rd,task_subcomment,"In theory you should not load anything from Prototype, on the assumption it may disappear at any moment.","In theory you should not load anything from Prototype, on the assumption it may disappear at any moment.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-90,TRUE,"['In theory you should not load anything from Prototype, on the assumption it may disappear at any moment.']",NA,0,"In theory you should not load anything from Prototype, on the assumption it may disappear at any moment.",SOLUTION USAGE,, 17570,server prototype.wikimedia.org has no https,"Are you saying that enWP should be looking to stop using that gadget, or at least calling that js gadget from that server and have it hosted elsewhere?",1323416690,PHID-USER-bmenasgfntvftznu6wxs,PHID-TASK-s6esjv72iihkh6eqj5rd,task_subcomment,"Are you saying that enWP should be looking to stop using that gadget, or at least calling that js gadget from that server and have it hosted elsewhere?","Are you saying that enWP should be looking to stop using that gadget, or at least calling that js gadget from that server and have it hosted elsewhere?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['Are you saying that enWP should be looking to stop using that gadget, or at least calling that js gadget from that server and have it hosted elsewhere?']",NA,0,"Are you saying that enWP should be looking to stop using that gadget, or at least calling that js gadget from that server and have it hosted elsewhere?",INVESTIGATION AND EXPLORATION,, 17571,server prototype.wikimedia.org has no https,"I believe we are planning to kill off the prototype instances for labs setup, But I don't know how far off that is.",1323415953,PHID-USER-hwuumsjqciw7ji5qhpc7,PHID-TASK-s6esjv72iihkh6eqj5rd,task_subcomment,"I believe we are planning to kill off the prototype instances for labs setup, But I don't know how far off that is.","I believe we are planning to kill off the prototype instances for labs setup, But I don't know how far off that is.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"[""I believe we are planning to kill off the prototype instances for labs setup, But I don't know how far off that is.""]",NA,0,"I believe we are planning to kill off the prototype instances for labs setup, But I don't know how far off that is.",FUTURE PLANS,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,On wikipedia I use Yurivict.,SOCIAL CONVERSATION,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,"""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\",OBSERVED BUG BEHAVIOR,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,", ""Also you IMO don",NA,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,"Now this leaves me confused, and unable to use single login at all.",MOTIVATION,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,User Name from Wikipedia can't be used to login to phabricator.,OBSERVED BUG BEHAVIOR,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,"When I try to login to phabricator, wikipedia password doesn't work.",OBSERVED BUG BEHAVIOR,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,Register,NA,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,Login,NA,, 17822,User Name from Wikipedia can't be used to login to phabricator,"On wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",1417050177,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_description,"User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on https://www.mediawiki.org/ says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.","User Name from Wikipedia can't be used to login to phabricator./n/nOn wikipedia I use Yurivict. When I try to login to phabricator, wikipedia password doesn't work. ""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn't lead to ""Register"" function at all, only to ""Login"". Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account. So I had to bail out and create this Yuri271 acct to even be able to create this PR. All these problems defeat the purpose of ""Sinogle login"". Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia. Now this leaves me confused, and unable to use single login at all.",Needs Triage,90,1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,declined,TRUE,c3,1,FALSE,FALSE,-31,TRUE,"[""User Name from Wikipedia can't be used to login to phabricator."", 'On wikipedia I use Yurivict.', ""When I try to login to phabricator, wikipedia password doesn't work."", '""Login or Register"" button on the ""Login or Register with LDAP"" screen doesn\'t lead to ""Register"" function at all, only to ""Login"".', 'Login screen on URL says there is no Yurivict account, but when I try to create the Yurivict account there, it fails and says there the similar account.', 'So I had to bail out and create this Yuri271 acct to even be able to create this PR.', 'All these problems defeat the purpose of ""Sinogle login"".', ""Also you IMO don't need to tell users LDAP login, this only introduces another concept (LDAP) in addition to MediaWiki, WikiMedia, WikiPedia."", 'Now this leaves me confused, and unable to use single login at all.']",TRUE,0,Sinogle login,NA,, 17823,User Name from Wikipedia can't be used to login to phabricator,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.",1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.","URL states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['URL states ""If that doesn\'t work, try unifying your account.', 'Finally, if you can not unify your account (or don\'t have an account at all yet), signup for MediaWiki.org.""', ""I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.""]",NA,0,"URL states ""If that doesn\",INVESTIGATION AND EXPLORATION,, 17823,User Name from Wikipedia can't be used to login to phabricator,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.",1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.","URL states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['URL states ""If that doesn\'t work, try unifying your account.', 'Finally, if you can not unify your account (or don\'t have an account at all yet), signup for MediaWiki.org.""', ""I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.""]",NA,0,"t have an account at all yet), signup for MediaWiki.org.""",INVESTIGATION AND EXPLORATION,, 17823,User Name from Wikipedia can't be used to login to phabricator,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.",1417056465,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following https://meta.wikimedia.org/wiki/Help:Unified_login#How_to_unify_your_accounts instead.","URL states ""If that doesn't work, try unifying your account. Finally, if you can not unify your account (or don't have an account at all yet), signup for MediaWiki.org."" I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['URL states ""If that doesn\'t work, try unifying your account.', 'Finally, if you can not unify your account (or don\'t have an account at all yet), signup for MediaWiki.org.""', ""I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.""]",NA,0,I'm sorry but there is nothing that could be fixed in Phabricator itself - this needs to be handled by following URL instead.,ISSUE CONTENT MANAGEMENT,, 17824,User Name from Wikipedia can't be used to login to phabricator,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",1417054635,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.","Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO.', 'Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general.', 'I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.']",NA,0,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO.",EXPECTED BEHAVIOR,, 17824,User Name from Wikipedia can't be used to login to phabricator,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",1417054635,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.","Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO.', 'Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general.', 'I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.']",NA,0,"Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general.",SOLUTION DISCUSSION,, 17824,User Name from Wikipedia can't be used to login to phabricator,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",1417054635,PHID-USER-hpjcdugjiwaoiwgklhnd,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.","Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO. Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general. I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['Once mediawiki rejects new account due to the name similarity, it should offer the user to consolidate login IMO.', 'Ask for the password for that other login, and ask to offer to consolidate, if consolidation is a desirable in general.', 'I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.']",NA,0,"I only wanted to report some unrelated bug in wikipedia, googled my way to phabricator and got lost in the login process in it.",OBSERVED BUG BEHAVIOR,, 17825,User Name from Wikipedia can't be used to login to phabricator,"https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.",1417050401,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.","URL It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"[""URL\n\nIt looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account."", 'Once you create a global account, login via mediawiki.org should work.']",NA,0,"Once you create a global account, login via mediawiki.org should work.",EXPECTED BEHAVIOR,, 17825,User Name from Wikipedia can't be used to login to phabricator,"https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.",1417050401,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.","URL It looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account. Once you create a global account, login via mediawiki.org should work.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"[""URL\n\nIt looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account."", 'Once you create a global account, login via mediawiki.org should work.']",NA,0,"URL\n\nIt looks like currently you don't have a global (across Wikimedia wikis) account, just a local (English Wikipedia) account.",INVESTIGATION AND EXPLORATION,, 17826,User Name from Wikipedia can't be used to login to phabricator,"LDAP login is for specific users that have an account on wikitech... Users who have that access would likely know The problem is you don't have a global account see https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict This is part of a wider issue, which already has an issue for it",1417050398,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-ohpp4da3hkjed775yze7,task_subcomment,"LDAP login is for specific users that have an account on wikitech... Users who have that access would likely know The problem is you don't have a global account see https://en.wikipedia.org/wiki/Special:CentralAuth/Yurivict This is part of a wider issue, which already has an issue for it","LDAP login is for specific users that have an account on wikitech... Users who have that access would likely know The problem is you don't have a global account see URL This is part of a wider issue, which already has an issue for it",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"[""LDAP login is for specific users that have an account on wikitech... Users who have that access would likely know\n\nThe problem is you don't have a global account see URL\n\nThis is part of a wider issue, which already has an issue for it""]",NA,0,"LDAP login is for specific users that have an account on wikitech... Users who have that access would likely know\n\nThe problem is you don't have a global account see URL\n\nThis is part of a wider issue, which already has an issue for it",INVESTIGATION AND EXPLORATION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,py34 pwb.py loads externals/httplib2 even if it is empty.,OBSERVED BUG BEHAVIOR,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.",INVESTIGATION AND EXPLORATION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,Steps to reproduce:\n1.,BUG REPRODUCTION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,Uninstall httplib2 from python34 environment.,WORKAROUND,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.,BUG REPRODUCTION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,Did you clone without --recursive?,INVESTIGATION AND EXPLORATION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,"Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2.",INVESTIGATION AND EXPLORATION,, 17889,py34 pwb.py loads externals/httplib2 even if it is empty,"Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",1413787200,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_description,"py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal","py34 pwb.py loads externals/httplib2 even if it is empty./n/nNormally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory. Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2. Steps to reproduce: 1. Uninstall httplib2 from python34 environment. 2. rm -rf externals/httplib2 3. mkdir externals/httplib2 4. python34 pwb.py version Expected results: An error like: Python module httplib2 >= 0.6.0 is required. Did you clone without --recursive? Try running 'git submodule update --init' Actual results: AttributeError: 'module' object has no attribute '__version__' -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1413869656,NA,resolved,TRUE,c3,1,TRUE,FALSE,-37,TRUE,"['py34 pwb.py loads externals/httplib2 even if it is empty.', 'Normally if the externals/httplib2 directory is empty, and there is no httplib2 installed on the system, running pwb.py will report an error and advise the user to use git recursive to install httplib2 into the externals directory.', ""Python 3.4 (and 3.5 nightlys) will 'import' the directory externals/httplib2 even when it is empty, causing pwb.py to fail when it attempts to access 'httplib2.__version__' which doesnt exist in the empty directory externals/httplib2."", 'Steps to reproduce:\n1.', 'Uninstall httplib2 from python34 environment.', '2. rm -rf externals/httplib2\n3. mkdir externals/httplib2\n4. python34 pwb.py version\n\nExpected results:\nAn error like:\nPython module httplib2 >= 0.6.0 is required.', 'Did you clone without --recursive?', ""Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal""]",TRUE,0,Try running 'git submodule update --init'\n\nActual results:\nAttributeError: 'module' object has no attribute '__version__'\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17890,py34 pwb.py loads externals/httplib2 even if it is empty,"Change 167533 merged by jenkins-bot: Check httplib2.__version__ exists https://gerrit.wikimedia.org/r/167533",1413805917,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_subcomment,"Change 167533 merged by jenkins-bot: Check httplib2.__version__ exists https://gerrit.wikimedia.org/r/167533","Change 167533 merged by jenkins-bot: Check httplib2.__version__ exists GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-37,TRUE,['Change 167533 merged by jenkins-bot:\nCheck httplib2.__version__ exists\n\nGERRIT_URL'],NA,0,Change 167533 merged by jenkins-bot:\nCheck httplib2.__version__ exists\n\nGERRIT_URL,TASK PROGRESS,, 17891,py34 pwb.py loads externals/httplib2 even if it is empty,"Change 167533 had a related patch set uploaded by John Vandenberg: Check httplib2.__version__ exists https://gerrit.wikimedia.org/r/167533",1413787584,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-bbwunlkc2m33c5ycsv6d,task_subcomment,"Change 167533 had a related patch set uploaded by John Vandenberg: Check httplib2.__version__ exists https://gerrit.wikimedia.org/r/167533","Change 167533 had a related patch set uploaded by John Vandenberg: Check httplib2.__version__ exists GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-37,TRUE,['Change 167533 had a related patch set uploaded by John Vandenberg:\nCheck httplib2.__version__ exists\n\nGERRIT_URL'],NA,0,Change 167533 had a related patch set uploaded by John Vandenberg:\nCheck httplib2.__version__ exists\n\nGERRIT_URL,TASK PROGRESS,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,www.,NA,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,*.wikimedia.org has a bad certificate.,OBSERVED BUG BEHAVIOR,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).",OBSERVED BUG BEHAVIOR,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,"However, when accessing these www.",BUG REPRODUCTION,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,"sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.",OBSERVED BUG BEHAVIOR,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,"As such, visiting URL throws an invalid certificate error.",OBSERVED BUG BEHAVIOR,, 17900,www.*.wikimedia.org has a bad certificate,"Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",1413549360,PHID-USER-uo5cuzto35jwltfdhy44,PHID-TASK-qjbmegbvpp33oxxamp6u,task_description,"www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting https://www.en.wikipedia.org throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal","www.*.wikimedia.org has a bad certificate./n/nSites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org). However, when accessing these www. sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain. As such, visiting URL throws an invalid certificate error. -------------------------- **Version**: wmf-deployment **Severity**: normal",Needs Triage,90,1413549934,NA,declined,TRUE,c3,1,FALSE,FALSE,-37,TRUE,"['www.', '*.wikimedia.org has a bad certificate.', 'Sites such as www.en.wikipedia.org and www.commons.wikimedia.org redirect to their non-www equivalents (en.wikipedia.org, commons.wikimedia.org).', 'However, when accessing these www.', 'sites over HTTPS there is a host mismatch, as wildcard certificates are not valid for multiple levels of subdomain.', 'As such, visiting URL throws an invalid certificate error.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",TRUE,0,--------------------------\n**Version**: wmf-deployment\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17901,www.*.wikimedia.org has a bad certificate,"(In reply to MZMcBride from comment #2) > There are older Bugzilla bugs about this, I believe. Specifically bug 1698.",1413550127,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-qjbmegbvpp33oxxamp6u,task_subcomment,"(In reply to MZMcBride from comment #2) > There are older Bugzilla bugs about this, I believe. Specifically bug 1698.","(In reply to MZMcBride from comment #2) QUOTE Specifically bug 1698.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-37,TRUE,['(In reply to MZMcBride from comment #2)\nQUOTE\n\nSpecifically bug 1698.'],NA,0,(In reply to MZMcBride from comment #2)\nQUOTE\n\nSpecifically bug 1698.,ISSUE CONTENT MANAGEMENT,, 17902,www.*.wikimedia.org has a bad certificate,"(In reply to Sam Reed (reedy) from comment #1) > Why are you visiting these domains? As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.",1413549919,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-qjbmegbvpp33oxxamp6u,task_subcomment,"(In reply to Sam Reed (reedy) from comment #1) > Why are you visiting these domains? As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.","(In reply to Sam Reed (reedy) from comment #1) QUOTE As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-37,TRUE,"[""(In reply to Sam Reed (reedy) from comment #1)\nQUOTE\n\nAs I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly."", 'There are older Bugzilla bugs about this, I believe.']",NA,0,"There are older Bugzilla bugs about this, I believe.",ISSUE CONTENT MANAGEMENT,, 17902,www.*.wikimedia.org has a bad certificate,"(In reply to Sam Reed (reedy) from comment #1) > Why are you visiting these domains? As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.",1413549919,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-qjbmegbvpp33oxxamp6u,task_subcomment,"(In reply to Sam Reed (reedy) from comment #1) > Why are you visiting these domains? As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.","(In reply to Sam Reed (reedy) from comment #1) QUOTE As I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly. There are older Bugzilla bugs about this, I believe.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-37,TRUE,"[""(In reply to Sam Reed (reedy) from comment #1)\nQUOTE\n\nAs I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly."", 'There are older Bugzilla bugs about this, I believe.']",NA,0,"(In reply to Sam Reed (reedy) from comment #1)\nQUOTE\n\nAs I understand it, there's a reason that www.commons.wikimedia.org and similar URLs were created: it's convention and standard practice for this type of domain format to function properly.",SOLUTION USAGE,, 17903,www.*.wikimedia.org has a bad certificate,"Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...",1413549698,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-qjbmegbvpp33oxxamp6u,task_subcomment,"Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...","Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-37,TRUE,"['Why are you visitng these domains?', ""There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...""]",NA,0,Why are you visitng these domains?,SOLUTION USAGE,, 17903,www.*.wikimedia.org has a bad certificate,"Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...",1413549698,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-qjbmegbvpp33oxxamp6u,task_subcomment,"Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...","Why are you visitng these domains? There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-37,TRUE,"['Why are you visitng these domains?', ""There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...""]",NA,0,"There isn't any nice way of fixing this, as WMF isn't going to waste money on buying sub-subdomain SSL certs...",SOLUTION DISCUSSION,, 17986,SSLError on requesting data from Wikidata,"When trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",1412156760,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_description,"SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal","SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1412591353,NA,invalid,TRUE,c3,1,FALSE,FALSE,-40,TRUE,"['SSLError on requesting data from Wikidata.', 'When trying to get() an item from wikidata I get the following SSL related error:\n\nERROR: Traceback (most recent call last):\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit\n headers=headers, body=body)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper\n return method(*__args, **__kw)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request\n raise request.data\nSSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib\n\n\nTo reproduce:\nimport pywikibot\nrepo = pywikibot.Site().data_repository()\nitem = pywikibot.ItemPage(repo, \'Q4115189\')\nitem.get()\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,SSLError on requesting data from Wikidata.,OBSERVED BUG BEHAVIOR,, 17986,SSLError on requesting data from Wikidata,"When trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",1412156760,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_description,"SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal","SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1412591353,NA,invalid,TRUE,c3,1,FALSE,FALSE,-40,TRUE,"['SSLError on requesting data from Wikidata.', 'When trying to get() an item from wikidata I get the following SSL related error:\n\nERROR: Traceback (most recent call last):\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit\n headers=headers, body=body)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper\n return method(*__args, **__kw)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request\n raise request.data\nSSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib\n\n\nTo reproduce:\nimport pywikibot\nrepo = pywikibot.Site().data_repository()\nitem = pywikibot.ItemPage(repo, \'Q4115189\')\nitem.get()\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,"When trying to get() an item from wikidata I get the following SSL related error:\n\nERROR: Traceback (most recent call last):\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit\n headers=headers, body=body)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper\n return method(*__args, **__kw)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request\n raise request.data\nSSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib\n\n\nTo reproduce:\nimport pywikibot\nrepo = pywikibot.Site().data_repository()\nitem = pywikibot.ItemPage(repo, \",OBSERVED BUG BEHAVIOR,, 17986,SSLError on requesting data from Wikidata,"When trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",1412156760,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_description,"SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal","SSLError on requesting data from Wikidata./n/nWhen trying to get() an item from wikidata I get the following SSL related error: ERROR: Traceback (most recent call last): File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit headers=headers, body=body) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper return method(*__args, **__kw) File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request raise request.data SSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib To reproduce: import pywikibot repo = pywikibot.Site().data_repository() item = pywikibot.ItemPage(repo, 'Q4115189') item.get() -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1412591353,NA,invalid,TRUE,c3,1,FALSE,FALSE,-40,TRUE,"['SSLError on requesting data from Wikidata.', 'When trying to get() an item from wikidata I get the following SSL related error:\n\nERROR: Traceback (most recent call last):\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/data/api.py"", line 452, in submit\n headers=headers, body=body)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/tools.py"", line 367, in wrapper\n return method(*__args, **__kw)\n File ""/usr/local/lib/python2.7/dist-packages/pywikibot-2.0b1-py2.7.egg/pywikibot/comms/http.py"", line 258, in request\n raise request.data\nSSLError: [Errno 185090050] _ssl.c:344: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib\n\n\nTo reproduce:\nimport pywikibot\nrepo = pywikibot.Site().data_repository()\nitem = pywikibot.ItemPage(repo, \'Q4115189\')\nitem.get()\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,)\nitem.get()\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 17987,SSLError on requesting data from Wikidata,"The upstream issue is https://github.com/jcgregorio/httplib2/issues/252 tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.",1417113110,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"The upstream issue is https://github.com/jcgregorio/httplib2/issues/252 tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.","The upstream issue is URL tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['The upstream issue is URL\n\ntl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root.', 'WORKAROUNDSs: \n - fix the permissions manually\n - install pywikibot into a virtualenv\n - remove the pip installed httplib2 and replace by the distribution one\n - use pwb.py\n\nand maybe\n - install the bundled httplib2 in externals/\n\nalso works.']",NA,0,"The upstream issue is URL\n\ntl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root.",INVESTIGATION AND EXPLORATION,, 17987,SSLError on requesting data from Wikidata,"The upstream issue is https://github.com/jcgregorio/httplib2/issues/252 tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.",1417113110,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"The upstream issue is https://github.com/jcgregorio/httplib2/issues/252 tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.","The upstream issue is URL tl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root. WORKAROUNDSs: - fix the permissions manually - install pywikibot into a virtualenv - remove the pip installed httplib2 and replace by the distribution one - use pwb.py and maybe - install the bundled httplib2 in externals/ also works.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['The upstream issue is URL\n\ntl;dr: the permissions in the .tar.gz on pypi are wrong, and these permissions are restored when pip installing as root.', 'WORKAROUNDSs: \n - fix the permissions manually\n - install pywikibot into a virtualenv\n - remove the pip installed httplib2 and replace by the distribution one\n - use pwb.py\n\nand maybe\n - install the bundled httplib2 in externals/\n\nalso works.']",NA,0,workaround: \n - fix the permissions manually\n - install pywikibot into a virtualenv\n - remove the pip installed httplib2 and replace by the distribution one\n - use pwb.py\n\nand maybe\n - install the bundled httplib2 in externals/\n\nalso works.,WORKAROUND,, 17988,SSLError on requesting data from Wikidata,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,1417110306,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['An update on this.', 'In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot.', 'Strange and weird but unlikely to be related to pywikibot itself.']",NA,0,An update on this.,TASK PROGRESS,, 17988,SSLError on requesting data from Wikidata,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,1417110306,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['An update on this.', 'In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot.', 'Strange and weird but unlikely to be related to pywikibot itself.']",NA,0,In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot.,INVESTIGATION AND EXPLORATION,, 17988,SSLError on requesting data from Wikidata,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,1417110306,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,An update on this. In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot. Strange and weird but unlikely to be related to pywikibot itself.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-31,TRUE,"['An update on this.', 'In Amsterdam we found at that it seems as though my installation (ubuntu or python) made the cert file not readable by the process running pywikibot.', 'Strange and weird but unlikely to be related to pywikibot itself.']",NA,0,Strange and weird but unlikely to be related to pywikibot itself.,INVESTIGATION AND EXPLORATION,, 17989,SSLError on requesting data from Wikidata,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,1412595221,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Yes.', ""It's used by people using pywikibot-as-a-portable-package via pwb.py."", ""I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).""]",NA,0,Yes.,SOCIAL CONVERSATION,, 17989,SSLError on requesting data from Wikidata,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,1412595221,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Yes.', ""It's used by people using pywikibot-as-a-portable-package via pwb.py."", ""I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).""]",NA,0,It's used by people using pywikibot-as-a-portable-package via pwb.py.,SOLUTION USAGE,, 17989,SSLError on requesting data from Wikidata,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,1412595221,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,Yes. It's used by people using pywikibot-as-a-portable-package via pwb.py. I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Yes.', ""It's used by people using pywikibot-as-a-portable-package via pwb.py."", ""I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).""]",NA,0,I'm not sure why your system decided to a) use that directory (instead of using the system-installed one) or b) why it couldn't find it's cacerts file (which is included in the externals/httplib2 directory).,INVESTIGATION AND EXPLORATION,, 17990,SSLError on requesting data from Wikidata,Is the httplib2 in core/externals necessary?,1412595068,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,Is the httplib2 in core/externals necessary?,Is the httplib2 in core/externals necessary?,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,['Is the httplib2 in core/externals necessary?'],NA,0,Is the httplib2 in core/externals necessary?,INVESTIGATION AND EXPLORATION,, 17991,SSLError on requesting data from Wikidata,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",1412591289,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.","Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['Sorry about that.', 'Me getting confused between httplib and requests.', 'httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt\n\n---\n\nI finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.']",NA,0,Sorry about that.,SOCIAL CONVERSATION,, 17991,SSLError on requesting data from Wikidata,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",1412591289,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.","Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['Sorry about that.', 'Me getting confused between httplib and requests.', 'httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt\n\n---\n\nI finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.']",NA,0,Me getting confused between httplib and requests.,SOCIAL CONVERSATION,, 17991,SSLError on requesting data from Wikidata,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",1412591289,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.","Sorry about that. Me getting confused between httplib and requests. httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt --- I finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['Sorry about that.', 'Me getting confused between httplib and requests.', 'httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt\n\n---\n\nI finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.']",NA,0,httplib2.CA_CERTS gives me /usr/local/lib/python2.7/dist-packages/httplib2-0.9-py2.7.egg/httplib2/cacerts.txt\n\n---\n\nI finally got things to work by deleting the httplib2 directory in the externals folder of pywikibot.,WORKAROUND,, 17992,SSLError on requesting data from Wikidata,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",1412590488,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?","Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. QUOTE QUOTE This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Note that we use *httplib2*, not requests!', 'Please try the following\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType ""help"", ""copyright"", ""credits"" or ""license"" for more information.', ""QUOTE\nQUOTE\n\nThis gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv."", 'What do you get, and does that file exist?']",NA,0,"Note that we use *httplib2*, not requests!",SOLUTION USAGE,, 17992,SSLError on requesting data from Wikidata,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",1412590488,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?","Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. QUOTE QUOTE This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Note that we use *httplib2*, not requests!', 'Please try the following\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType ""help"", ""copyright"", ""credits"" or ""license"" for more information.', ""QUOTE\nQUOTE\n\nThis gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv."", 'What do you get, and does that file exist?']",NA,0,"Please try the following\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType ""help"", ""copyright"", ""credits"" or ""license"" for more information.",WORKAROUND,, 17992,SSLError on requesting data from Wikidata,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",1412590488,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?","Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. QUOTE QUOTE This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Note that we use *httplib2*, not requests!', 'Please try the following\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType ""help"", ""copyright"", ""credits"" or ""license"" for more information.', ""QUOTE\nQUOTE\n\nThis gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv."", 'What do you get, and does that file exist?']",NA,0,"What do you get, and does that file exist?",INVESTIGATION AND EXPLORATION,, 17992,SSLError on requesting data from Wikidata,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",1412590488,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. >>> import httplib2 >>> httplib2.CA_CERTS This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?","Note that we use *httplib2*, not requests! Please try the following $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type ""help"", ""copyright"", ""credits"" or ""license"" for more information. QUOTE QUOTE This gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv. What do you get, and does that file exist?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Note that we use *httplib2*, not requests!', 'Please try the following\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56)\n[GCC 4.8.2] on linux2\nType ""help"", ""copyright"", ""credits"" or ""license"" for more information.', ""QUOTE\nQUOTE\n\nThis gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv."", 'What do you get, and does that file exist?']",NA,0,"QUOTE\nQUOTE\n\nThis gives me '/etc/ssl/certs/ca-certificates.crt' for my Ubuntu 14.04-packaged httplib2, and '/path/to/venv/lib/python2.6/site-packages/httplib2-0.8_pywikibot1-py2.6.egg/httplib2/cacerts.txt' for a virtualenv.",INVESTIGATION AND EXPLORATION,, 17993,SSLError on requesting data from Wikidata,@Merlijn: running httplib2 version 0.9,1412589009,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,@Merlijn: running httplib2 version 0.9,SCREEN_NAME: running httplib2 version 0.9,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,['SCREEN_NAME: running httplib2 version 0.9'],NA,0,SCREEN_NAME: running httplib2 version 0.9,BUG REPRODUCTION,, 17994,SSLError on requesting data from Wikidata,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.",1412588219,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.","SCREEN_NAME: SSL issue doesn't happen when I call pywikibot.version.getversion() SCREEN_NAME: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['SCREEN_NAME: SSL issue doesn\'t happen when I call pywikibot.version.getversion()\nSCREEN_NAME: Running ""pip install --upgrade httplib2"" didn\'t help (and on searching I find cacert.pem in the requests directory).', 'Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.', ""u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.""]",NA,0,SCREEN_NAME: SSL issue doesn\,SOCIAL CONVERSATION,, 17994,SSLError on requesting data from Wikidata,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.",1412588219,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.","SCREEN_NAME: SSL issue doesn't happen when I call pywikibot.version.getversion() SCREEN_NAME: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['SCREEN_NAME: SSL issue doesn\'t happen when I call pywikibot.version.getversion()\nSCREEN_NAME: Running ""pip install --upgrade httplib2"" didn\'t help (and on searching I find cacert.pem in the requests directory).', 'Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.', ""u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.""]",NA,0,t help (and on searching I find cacert.pem in the requests directory).,INVESTIGATION AND EXPLORATION,, 17994,SSLError on requesting data from Wikidata,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.",1412588219,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.","SCREEN_NAME: SSL issue doesn't happen when I call pywikibot.version.getversion() SCREEN_NAME: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['SCREEN_NAME: SSL issue doesn\'t happen when I call pywikibot.version.getversion()\nSCREEN_NAME: Running ""pip install --upgrade httplib2"" didn\'t help (and on searching I find cacert.pem in the requests directory).', 'Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.', ""u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.""]",NA,0,Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.,WORKAROUND,, 17994,SSLError on requesting data from Wikidata,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.",1412588219,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.","SCREEN_NAME: SSL issue doesn't happen when I call pywikibot.version.getversion() SCREEN_NAME: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['SCREEN_NAME: SSL issue doesn\'t happen when I call pywikibot.version.getversion()\nSCREEN_NAME: Running ""pip install --upgrade httplib2"" didn\'t help (and on searching I find cacert.pem in the requests directory).', 'Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.', ""u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.""]",NA,0,pip install --upgrade httplib2,INVESTIGATION AND EXPLORATION,, 17994,SSLError on requesting data from Wikidata,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.",1412588219,PHID-USER-uu7wg6g3b37dcktbje3a,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"@Fabian: SSL issue doesn't happen when I call pywikibot.version.getversion() @Merlijn: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1306991 it seems as though requests is broken for Ubuntu 14.04.","SCREEN_NAME: SSL issue doesn't happen when I call pywikibot.version.getversion() SCREEN_NAME: Running ""pip install --upgrade httplib2"" didn't help (and on searching I find cacert.pem in the requests directory). Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue. u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)' Reading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,"['SCREEN_NAME: SSL issue doesn\'t happen when I call pywikibot.version.getversion()\nSCREEN_NAME: Running ""pip install --upgrade httplib2"" didn\'t help (and on searching I find cacert.pem in the requests directory).', 'Completely reinstalled pywikibot (to try and remove any issues related to the egg installer but still the same issue.', ""u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.""]",NA,0,"u'[ssh] pywikibot-core.git (df93880, g4208, 2014/10/05, 23:53:47, n/a)'\n\nReading a bit at URL it seems as though requests is broken for Ubuntu 14.04.",INVESTIGATION AND EXPLORATION,, 17995,SSLError on requesting data from Wikidata,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",1412461344,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.","Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Apparently this is what you get if your certificates file is missing.', 'What version of httplib2 do you have installed, and was it installed by a package manager or with pip?', 'In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.']",NA,0,Apparently this is what you get if your certificates file is missing.,INVESTIGATION AND EXPLORATION,, 17995,SSLError on requesting data from Wikidata,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",1412461344,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.","Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Apparently this is what you get if your certificates file is missing.', 'What version of httplib2 do you have installed, and was it installed by a package manager or with pip?', 'In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.']",NA,0,"What version of httplib2 do you have installed, and was it installed by a package manager or with pip?",INVESTIGATION AND EXPLORATION,, 17995,SSLError on requesting data from Wikidata,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",1412461344,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.","Apparently this is what you get if your certificates file is missing. What version of httplib2 do you have installed, and was it installed by a package manager or with pip? In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"['Apparently this is what you get if your certificates file is missing.', 'What version of httplib2 do you have installed, and was it installed by a package manager or with pip?', 'In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.']",NA,0,"In the latter case, please pip install --upgrade httplib2; in the former case, a bug report for your distribution might be in order.",WORKAROUND,, 17996,SSLError on requesting data from Wikidata,Does this happen also when calling pywikibot.version.getversion()?,1412460875,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,Does this happen also when calling pywikibot.version.getversion()?,Does this happen also when calling pywikibot.version.getversion()?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,['Does this happen also when calling pywikibot.version.getversion()?'],NA,0,Does this happen also when calling pywikibot.version.getversion()?,INVESTIGATION AND EXPLORATION,, 17997,SSLError on requesting data from Wikidata,"Work for me with: >>> pywikibot.version.getversion() u'[ssh] pywikibot-core.git (a5744db, g4204, 2014/10/04, 18:56:45, OUTDATED)'",1412459970,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-w4js4xepsmk6fz75gkwe,task_subcomment,"Work for me with: >>> pywikibot.version.getversion() u'[ssh] pywikibot-core.git (a5744db, g4204, 2014/10/04, 18:56:45, OUTDATED)'","Work for me with: QUOTE u'[ssh] pywikibot-core.git (a5744db, g4204, 2014/10/04, 18:56:45, OUTDATED)'",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-39,TRUE,"[""Work for me with:\nQUOTE\nu'[ssh] pywikibot-core.git (a5744db, g4204, 2014/10/04, 18:56:45, OUTDATED)'""]",NA,0,"Work for me with:\nQUOTE\nu'[ssh] pywikibot-core.git (a5744db, g4204, 2014/10/04, 18:56:45, OUTDATED)'",BUG REPRODUCTION,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,"KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.",OBSERVED BUG BEHAVIOR,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,"If you have an account for that site, please add a line to user-config.py:\n\nusernames[\",WORKAROUND,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,][\,NA,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,] = \,NA,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,"""""""\n % {\",NA,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,": self.site.family.name,\n \",NA,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,: self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,Wild card '*' for lang in user_config does not allow login.,OBSERVED BUG BEHAVIOR,, 18094,Wild card '*' for lang in user_config does not allow login,"With this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",1407593760,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_description,"Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal","Wild card '*' for lang in user_config does not allow login./n/nWith this settings in user_config.py: usernames['wikipedia']['*'] = u'Mpaa' cannot login, while it can with: usernames['wikipedia']['en'] = u'Mpaa' The try clause in login.py fails because self.site.code is 'en' and not '*'. KeyError is raised (BTW it should be except KeyError ....) try: self.username = config.usernames[ self.site.family.name][self.site.code] except: raise NoUsername(u""""""\ ERROR: Username for %(fam_name)s:%(wiki_code)s is undefined. If you have an account for that site, please add a line to user-config.py: usernames['%(fam_name)s']['%(wiki_code)s'] = 'myUsername'"""""" % {'fam_name': self.site.family.name, 'wiki_code': self.site.code}) -------------------------- **Version**: core-(2.0) **Severity**: normal",Needs Triage,90,1409298908,NA,resolved,TRUE,c3,1,TRUE,FALSE,-47,TRUE,"[""Wild card '*' for lang in user_config does not allow login."", ""With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'."", 'KeyError is raised (BTW it should be except KeyError ....)\n\ntry:\n self.username = config.usernames[\n self.site.family.name][self.site.code]\nexcept:\n raise NoUsername(u""""""\\\nERROR: Username for %(fam_name)s:%(wiki_code)s is undefined.', 'If you have an account for that site, please add a line to user-config.py:\n\nusernames[\'%(fam_name)s\'][\'%(wiki_code)s\'] = \'myUsername\'""""""\n % {\'fam_name\': self.site.family.name,\n \'wiki_code\': self.site.code})\n\n--------------------------\n**Version**: core-(2.0)\n**Severity**: normal']",TRUE,0,"With this settings in user_config.py:\n usernames['wikipedia']['*'] = u'Mpaa'\ncannot login, while it can with:\n usernames['wikipedia']['en'] = u'Mpaa'\n\nThe try clause in login.py fails because self.site.code is 'en' and not '*'.",INVESTIGATION AND EXPLORATION,, 18095,Wild card '*' for lang in user_config does not allow login,"**gerritadmin** wrote: Change 156987 merged by jenkins-bot: Wild card '*' in user-config does not allow login https://gerrit.wikimedia.org/r/156987",1409275799,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-kczta4bqmdsayknyylrh,task_subcomment,"**gerritadmin** wrote: Change 156987 merged by jenkins-bot: Wild card '*' in user-config does not allow login https://gerrit.wikimedia.org/r/156987","**gerritadmin** wrote: Change 156987 merged by jenkins-bot: Wild card '*' in user-config does not allow login GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"[""**gerritadmin** wrote:\n\nChange 156987 merged by jenkins-bot:\nWild card '*' in user-config does not allow login\n\nGERRIT_URL""]",NA,0,**gerritadmin** wrote:\n\nChange 156987 merged by jenkins-bot:\nWild card '*' in user-config does not allow login\n\nGERRIT_URL,TASK PROGRESS,, 18096,Wild card '*' for lang in user_config does not allow login,"**gerritadmin** wrote: Change 156987 had a related patch set uploaded by John Vandenberg: Wild card '*' in user-config does not allow login https://gerrit.wikimedia.org/r/156987",1409272176,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-kczta4bqmdsayknyylrh,task_subcomment,"**gerritadmin** wrote: Change 156987 had a related patch set uploaded by John Vandenberg: Wild card '*' in user-config does not allow login https://gerrit.wikimedia.org/r/156987","**gerritadmin** wrote: Change 156987 had a related patch set uploaded by John Vandenberg: Wild card '*' in user-config does not allow login GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"[""**gerritadmin** wrote:\n\nChange 156987 had a related patch set uploaded by John Vandenberg:\nWild card '*' in user-config does not allow login\n\nGERRIT_URL""]",NA,0,**gerritadmin** wrote:\n\nChange 156987 had a related patch set uploaded by John Vandenberg:\nWild card '*' in user-config does not allow login\n\nGERRIT_URL,TASK PROGRESS,, 18097,Wild card '*' for lang in user_config does not allow login,"Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'",1407617580,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_subcomment,"Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'","Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ...\n\n# The dictionary usernames should contain a username for each site where you\n# have a bot account.', ""If you have a unique username for all languages of a\n# family , you can use '*'\n\nor\n\n# If you have a unique username for all languages of a family,\n# you can use '*'""]",NA,0,Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ...\n\n# The dictionary usernames should contain a username for each site where you\n# have a bot account.,INVESTIGATION AND EXPLORATION,, 18097,Wild card '*' for lang in user_config does not allow login,"Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'",1407617580,PHID-USER-43lnvui4hacyjrc2lflj,PHID-TASK-kczta4bqmdsayknyylrh,task_subcomment,"Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'","Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ... # The dictionary usernames should contain a username for each site where you # have a bot account. If you have a unique username for all languages of a # family , you can use '*' or # If you have a unique username for all languages of a family, # you can use '*'",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['Might not be a bug if this sentences in user_cong.py/cinfig2.py are not True ...\n\n# The dictionary usernames should contain a username for each site where you\n# have a bot account.', ""If you have a unique username for all languages of a\n# family , you can use '*'\n\nor\n\n# If you have a unique username for all languages of a family,\n# you can use '*'""]",NA,0,"If you have a unique username for all languages of a\n# family , you can use '*'\n\nor\n\n# If you have a unique username for all languages of a family,\n# you can use '*'",WORKAROUND,, 18504,Error 500 on login,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",1387359180,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_description,"Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor","Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",Needs Triage,90,1389815205,NA,declined,TRUE,c3,1,TRUE,FALSE,-81,TRUE,"['Error 500 on login.', 'First time I tried to login via Meta, I got an error 500.', ""This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error."", 'May be the same as bug 52749.', '--------------------------\n**Version**: unspecified\n**Severity**: minor']",TRUE,0,Error 500 on login.,OBSERVED BUG BEHAVIOR,, 18504,Error 500 on login,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",1387359180,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_description,"Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor","Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",Needs Triage,90,1389815205,NA,declined,TRUE,c3,1,TRUE,FALSE,-81,TRUE,"['Error 500 on login.', 'First time I tried to login via Meta, I got an error 500.', ""This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error."", 'May be the same as bug 52749.', '--------------------------\n**Version**: unspecified\n**Severity**: minor']",TRUE,0,"First time I tried to login via Meta, I got an error 500.",OBSERVED BUG BEHAVIOR,, 18504,Error 500 on login,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",1387359180,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_description,"Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor","Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",Needs Triage,90,1389815205,NA,declined,TRUE,c3,1,TRUE,FALSE,-81,TRUE,"['Error 500 on login.', 'First time I tried to login via Meta, I got an error 500.', ""This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error."", 'May be the same as bug 52749.', '--------------------------\n**Version**: unspecified\n**Severity**: minor']",TRUE,0,May be the same as bug 52749.,ISSUE CONTENT MANAGEMENT,, 18504,Error 500 on login,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",1387359180,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_description,"Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor","Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",Needs Triage,90,1389815205,NA,declined,TRUE,c3,1,TRUE,FALSE,-81,TRUE,"['Error 500 on login.', 'First time I tried to login via Meta, I got an error 500.', ""This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error."", 'May be the same as bug 52749.', '--------------------------\n**Version**: unspecified\n**Severity**: minor']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: minor,OBSERVED BUG BEHAVIOR,, 18504,Error 500 on login,"First time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",1387359180,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_description,"Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor","Error 500 on login./n/nFirst time I tried to login via Meta, I got an error 500. This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error. May be the same as bug 52749. -------------------------- **Version**: unspecified **Severity**: minor",Needs Triage,90,1389815205,NA,declined,TRUE,c3,1,TRUE,FALSE,-81,TRUE,"['Error 500 on login.', 'First time I tried to login via Meta, I got an error 500.', ""This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error."", 'May be the same as bug 52749.', '--------------------------\n**Version**: unspecified\n**Severity**: minor']",TRUE,0,"This might have been because I had cookies disabled for metrics.wmflabs.org: after I whitelisted it, I didn't get any error.",WORKAROUND,, 18505,Error 500 on login,"I'm closing this, nobody's reported anything similar and lots of people are logging in daily.",1389815205,PHID-USER-vbyvvtbztxaeuaxelxx4,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_subcomment,"I'm closing this, nobody's reported anything similar and lots of people are logging in daily.","I'm closing this, nobody's reported anything similar and lots of people are logging in daily.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-77,TRUE,"[""I'm closing this, nobody's reported anything similar and lots of people are logging in daily.""]",NA,0,"I'm closing this, nobody's reported anything similar and lots of people are logging in daily.",ACTION ON ISSUE ,, 18506,Error 500 on login,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",1387415490,PHID-USER-ud7f5gp5h3uqup6viq4e,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_subcomment,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby","We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-80,TRUE,"[""We haven't seen any reports of this."", ""I'll re-up the priority if we do."", '-Toby']",NA,0,-Toby,SOCIAL CONVERSATION,, 18506,Error 500 on login,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",1387415490,PHID-USER-ud7f5gp5h3uqup6viq4e,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_subcomment,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby","We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-80,TRUE,"[""We haven't seen any reports of this."", ""I'll re-up the priority if we do."", '-Toby']",NA,0,We haven't seen any reports of this.,ISSUE CONTENT MANAGEMENT,, 18506,Error 500 on login,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",1387415490,PHID-USER-ud7f5gp5h3uqup6viq4e,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_subcomment,"We haven't seen any reports of this. I'll re-up the priority if we do. -Toby","We haven't seen any reports of this. I'll re-up the priority if we do. -Toby",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-80,TRUE,"[""We haven't seen any reports of this."", ""I'll re-up the priority if we do."", '-Toby']",NA,0,I'll re-up the priority if we do.,ACTION ON ISSUE ,, 18507,Error 500 on login,"**bingle-admin** wrote: Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/1328",1387360025,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-kdo7tmfcvvv3unzvin4h,task_subcomment,"**bingle-admin** wrote: Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/1328","**bingle-admin** wrote: Prioritization and scheduling of this bug is tracked on Mingle card URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,['**bingle-admin** wrote:\n\nPrioritization and scheduling of this bug is tracked on Mingle card URL'],NA,0,**bingle-admin** wrote:\n\nPrioritization and scheduling of this bug is tracked on Mingle card URL,ISSUE CONTENT MANAGEMENT,, 18668,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",1412651160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_description,"HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major","HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * URL * URL * URL Example of HttpRequest failing on PHP 5.6: URL (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",High,80,1413197546,NA,resolved,TRUE,c3,1,TRUE,FALSE,-39,TRUE,"['HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).', 'Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.', 'Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.', 'If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.', 'See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).,OBSERVED BUG BEHAVIOR,, 18668,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",1412651160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_description,"HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major","HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * URL * URL * URL Example of HttpRequest failing on PHP 5.6: URL (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",High,80,1413197546,NA,resolved,TRUE,c3,1,TRUE,FALSE,-39,TRUE,"['HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).', 'Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.', 'Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.', 'If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.', 'See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.",INVESTIGATION AND EXPLORATION,, 18668,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",1412651160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_description,"HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major","HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * URL * URL * URL Example of HttpRequest failing on PHP 5.6: URL (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",High,80,1413197546,NA,resolved,TRUE,c3,1,TRUE,FALSE,-39,TRUE,"['HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).', 'Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.', 'Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.', 'If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.', 'See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.,MOTIVATION,, 18668,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",1412651160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_description,"HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major","HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * URL * URL * URL Example of HttpRequest failing on PHP 5.6: URL (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",High,80,1413197546,NA,resolved,TRUE,c3,1,TRUE,FALSE,-39,TRUE,"['HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).', 'Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.', 'Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.', 'If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.', 'See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.",SOLUTION DISCUSSION,, 18668,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",1412651160,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_description,"HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * http://php.net/manual/en/curl.constants.php#constant.curlopt-closepolicy * https://gerrit.wikimedia.org/r/#/c/159159/ * https://bugzilla.wikimedia.org/show_bug.cgi?id=70570 Example of HttpRequest failing on PHP 5.6: https://travis-ci.org/wikimedia/mediawiki-core/jobs/37159310 (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major","HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined)./n/nConstants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0. Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly. If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6. See also: * URL * URL * URL Example of HttpRequest failing on PHP 5.6: URL (lines 305...342) -------------------------- **Version**: unspecified **Severity**: major",High,80,1413197546,NA,resolved,TRUE,c3,1,TRUE,FALSE,-39,TRUE,"['HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined).', 'Constants CURLOPT_CLOSEPOLICY, CURLCLOSEPOLICY_LEAST_RECENTLY_USED and others are not defined as they were removed in PHP 5.6.0.', 'Tests should probably be updated to only test the ones relevant for the CurlHttpRequest class to function properly.', 'If those include constants removed in PHP 5.6, then we should fix the code to use a different method in PHP 5.6.', 'See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,See also:\n* URL\n* URL\n* URL\n\nExample of HttpRequest failing on PHP 5.6:\nURL (lines 305...342)\n\n--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 18669,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),https://travis-ci.org/Krinkle/mediawiki-core/jobs/37801162 (current master on PHP 5.6) no longer shows any CURL related errors.,1413197546,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-kneronwrmdjoh2wdb3kl,task_subcomment,https://travis-ci.org/Krinkle/mediawiki-core/jobs/37801162 (current master on PHP 5.6) no longer shows any CURL related errors.,URL (current master on PHP 5.6) no longer shows any CURL related errors.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-38,TRUE,['URL (current master on PHP 5.6) no longer shows any CURL related errors.'],NA,0,URL (current master on PHP 5.6) no longer shows any CURL related errors.,BUG REPRODUCTION,, 18670,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"Anything left to do here, or did the merged patch fix this bug report?",1413138585,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-kneronwrmdjoh2wdb3kl,task_subcomment,"Anything left to do here, or did the merged patch fix this bug report?","Anything left to do here, or did the merged patch fix this bug report?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-38,TRUE,"['Anything left to do here, or did the merged patch fix this bug report?']",NA,0,"Anything left to do here, or did the merged patch fix this bug report?",TASK PROGRESS,, 18671,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"**gerritadmin** wrote: Change 162825 merged by jenkins-bot: HttpTest: Update cURL constants array https://gerrit.wikimedia.org/r/162825",1412720896,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-kneronwrmdjoh2wdb3kl,task_subcomment,"**gerritadmin** wrote: Change 162825 merged by jenkins-bot: HttpTest: Update cURL constants array https://gerrit.wikimedia.org/r/162825","**gerritadmin** wrote: Change 162825 merged by jenkins-bot: HttpTest: Update cURL constants array GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,['**gerritadmin** wrote:\n\nChange 162825 merged by jenkins-bot:\nHttpTest: Update cURL constants array\n\nGERRIT_URL'],NA,0,**gerritadmin** wrote:\n\nChange 162825 merged by jenkins-bot:\nHttpTest: Update cURL constants array\n\nGERRIT_URL,TASK PROGRESS,, 18672,HttpRequest: Failing under PHP 5.6 (CURLOPT_CLOSEPOLICY not defined),"**gerritadmin** wrote: Change 162825 had a related patch set uploaded by Dan-nl: Updated cURL constants array https://gerrit.wikimedia.org/r/162825",1412705993,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-kneronwrmdjoh2wdb3kl,task_subcomment,"**gerritadmin** wrote: Change 162825 had a related patch set uploaded by Dan-nl: Updated cURL constants array https://gerrit.wikimedia.org/r/162825","**gerritadmin** wrote: Change 162825 had a related patch set uploaded by Dan-nl: Updated cURL constants array GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-39,TRUE,['**gerritadmin** wrote:\n\nChange 162825 had a related patch set uploaded by Dan-nl:\nUpdated cURL constants array\n\nGERRIT_URL'],NA,0,**gerritadmin** wrote:\n\nChange 162825 had a related patch set uploaded by Dan-nl:\nUpdated cURL constants array\n\nGERRIT_URL,TASK PROGRESS,, 18745,Login as another user no longer works,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066",1410804960,PHID-USER-nv2bu7uh3huvidyjo4lk,PHID-TASK-6mimi76qa47o25ubseql,task_description,"Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066","Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: URL",High,80,1411418851,NA,resolved,TRUE,c3,1,FALSE,FALSE,-42,TRUE,"['Login as another user no longer works.', ""If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out."", ""This is annoying and shouldn't have happened."", '--------------------------\n**Version**: 1.24rc\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Login as another user no longer works.,OBSERVED BUG BEHAVIOR,, 18745,Login as another user no longer works,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066",1410804960,PHID-USER-nv2bu7uh3huvidyjo4lk,PHID-TASK-6mimi76qa47o25ubseql,task_description,"Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066","Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: URL",High,80,1411418851,NA,resolved,TRUE,c3,1,FALSE,FALSE,-42,TRUE,"['Login as another user no longer works.', ""If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out."", ""This is annoying and shouldn't have happened."", '--------------------------\n**Version**: 1.24rc\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,--------------------------\n**Version**: 1.24rc\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 18745,Login as another user no longer works,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066",1410804960,PHID-USER-nv2bu7uh3huvidyjo4lk,PHID-TASK-6mimi76qa47o25ubseql,task_description,"Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066","Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: URL",High,80,1411418851,NA,resolved,TRUE,c3,1,FALSE,FALSE,-42,TRUE,"['Login as another user no longer works.', ""If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out."", ""This is annoying and shouldn't have happened."", '--------------------------\n**Version**: 1.24rc\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out.",OBSERVED BUG BEHAVIOR,, 18745,Login as another user no longer works,"If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066",1410804960,PHID-USER-nv2bu7uh3huvidyjo4lk,PHID-TASK-6mimi76qa47o25ubseql,task_description,"Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71066","Login as another user no longer works./n/nIf you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out. This is annoying and shouldn't have happened. -------------------------- **Version**: 1.24rc **Severity**: normal **See Also**: URL",High,80,1411418851,NA,resolved,TRUE,c3,1,FALSE,FALSE,-42,TRUE,"['Login as another user no longer works.', ""If you're already logged in, you can not longer directly log in as another user (such as with bots, different privilege or role accounts, sockpuppets, etc) without first logging out."", ""This is annoying and shouldn't have happened."", '--------------------------\n**Version**: 1.24rc\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,This is annoying and shouldn't have happened.,MOTIVATION,, 18746,Login as another user no longer works,My bad. Thanks for the clarification and sorry for the confusion :),1411515082,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,My bad. Thanks for the clarification and sorry for the confusion :),My bad. Thanks for the clarification and sorry for the confusion :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,"['My bad.', 'Thanks for the clarification and sorry for the confusion :)']",NA,0,My bad.,SOCIAL CONVERSATION,, 18746,Login as another user no longer works,My bad. Thanks for the clarification and sorry for the confusion :),1411515082,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,My bad. Thanks for the clarification and sorry for the confusion :),My bad. Thanks for the clarification and sorry for the confusion :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,"['My bad.', 'Thanks for the clarification and sorry for the confusion :)']",NA,0,Thanks for the clarification and sorry for the confusion :),SOCIAL CONVERSATION,, 18747,Login as another user no longer works,"**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) > (Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior > if a user types ""Special:UserLogin"" in the search box or address bar, or > otherwise directly visits the login page.) Tested and confirmed on Beta Labs. Thanks Bartosz.",1411514434,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) > (Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior > if a user types ""Special:UserLogin"" in the search box or address bar, or > otherwise directly visits the login page.) Tested and confirmed on Beta Labs. Thanks Bartosz.","**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) QUOTE QUOTE QUOTE Tested and confirmed on Beta Labs. Thanks Bartosz.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,"['**swalling** wrote:\n\n(In reply to Bartosz Dziewo<77><6F>ski from comment #21)\nQUOTE\nQUOTE\nQUOTE\n\nTested and confirmed on Beta Labs.', 'Thanks Bartosz.']",NA,0,**swalling** wrote:\n\n(In reply to Bartosz Dziewo<77><6F>ski from comment #21)\nQUOTE\nQUOTE\nQUOTE\n\nTested and confirmed on Beta Labs.,TESTING,, 18747,Login as another user no longer works,"**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) > (Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior > if a user types ""Special:UserLogin"" in the search box or address bar, or > otherwise directly visits the login page.) Tested and confirmed on Beta Labs. Thanks Bartosz.",1411514434,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) > (Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior > if a user types ""Special:UserLogin"" in the search box or address bar, or > otherwise directly visits the login page.) Tested and confirmed on Beta Labs. Thanks Bartosz.","**swalling** wrote: (In reply to Bartosz Dziewo<77><6F>ski from comment #21) QUOTE QUOTE QUOTE Tested and confirmed on Beta Labs. Thanks Bartosz.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,"['**swalling** wrote:\n\n(In reply to Bartosz Dziewo<77><6F>ski from comment #21)\nQUOTE\nQUOTE\nQUOTE\n\nTested and confirmed on Beta Labs.', 'Thanks Bartosz.']",NA,0,Thanks Bartosz.,SOCIAL CONVERSATION,, 18748,Login as another user no longer works,"(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)",1411514215,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)","(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,"[""(Per bug 15484 comment 27 it hasn't."", 'The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)']",NA,0,"The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)",SOLUTION USAGE,, 18748,Login as another user no longer works,"(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)",1411514215,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)","(Per bug 15484 comment 27 it hasn't. The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,"[""(Per bug 15484 comment 27 it hasn't."", 'The fix here only changes any behavior if a user types ""Special:UserLogin"" in the search box or address bar, or otherwise directly visits the login page.)']",NA,0,(Per bug 15484 comment 27 it hasn't.,ISSUE CONTENT MANAGEMENT,, 18749,Login as another user no longer works,So to be clear the fix has reopened bug 15484,1411512765,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,So to be clear the fix has reopened bug 15484,So to be clear the fix has reopened bug 15484,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,['So to be clear the fix has reopened bug 15484'],NA,0,So to be clear the fix has reopened bug 15484,ACTION ON ISSUE ,, 18750,Login as another user no longer works,Backported.,1411418851,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,Backported.,Backported.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,['Backported.'],NA,0,Backported.,CONTRIBUTION AND COMMITMENT,, 18751,Login as another user no longer works,"Change 162120 merged by jenkins-bot: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/162120",1411418407,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Change 162120 merged by jenkins-bot: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/162120","Change 162120 merged by jenkins-bot: Allow logged-in users to view and use the login form again GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,['Change 162120 merged by jenkins-bot:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL'],NA,0,Change 162120 merged by jenkins-bot:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL,TASK PROGRESS,, 18752,Login as another user no longer works,"Change 162120 had a related patch set uploaded by Legoktm: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/162120",1411417955,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Change 162120 had a related patch set uploaded by Legoktm: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/162120","Change 162120 had a related patch set uploaded by Legoktm: Allow logged-in users to view and use the login form again GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,['Change 162120 had a related patch set uploaded by Legoktm:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL'],NA,0,Change 162120 had a related patch set uploaded by Legoktm:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL,TASK PROGRESS,, 18753,Login as another user no longer works,"Patch merged in master, leaving this open until it's clean if we need to backport to 1.24, or if it will be included.",1411395534,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Patch merged in master, leaving this open until it's clean if we need to backport to 1.24, or if it will be included.","Patch merged in master, leaving this open until it's clean if we need to backport to 1.24, or if it will be included.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-41,TRUE,"[""Patch merged in master, leaving this open until it's clean if we need to backport to 1.24, or if it will be included.""]",NA,0,"Patch merged in master, leaving this open until it's clean if we need to backport to 1.24, or if it will be included.",TASK PROGRESS,, 18754,Login as another user no longer works,"Change 161465 merged by jenkins-bot: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/161465",1411395359,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Change 161465 merged by jenkins-bot: Allow logged-in users to view and use the login form again https://gerrit.wikimedia.org/r/161465","Change 161465 merged by jenkins-bot: Allow logged-in users to view and use the login form again GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,['Change 161465 merged by jenkins-bot:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL'],NA,0,Change 161465 merged by jenkins-bot:\nAllow logged-in users to view and use the login form again\n\nGERRIT_URL,TASK PROGRESS,, 18755,Login as another user no longer works,"Change 161465 had a related patch set uploaded by Bartosz Dziewo<77><6F>ski: Allow logged-in users to view and use the login form https://gerrit.wikimedia.org/r/161465",1411140218,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Change 161465 had a related patch set uploaded by Bartosz Dziewo<77><6F>ski: Allow logged-in users to view and use the login form https://gerrit.wikimedia.org/r/161465","Change 161465 had a related patch set uploaded by Bartosz Dziewo<77><6F>ski: Allow logged-in users to view and use the login form GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-41,TRUE,['Change 161465 had a related patch set uploaded by Bartosz Dziewo<77><6F>ski:\nAllow logged-in users to view and use the login form\n\nGERRIT_URL'],NA,0,Change 161465 had a related patch set uploaded by Bartosz Dziewo<77><6F>ski:\nAllow logged-in users to view and use the login form\n\nGERRIT_URL,TASK PROGRESS,, 18756,Login as another user no longer works,*** Bug 69475 has been marked as a duplicate of this bug. ***,1410978978,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,*** Bug 69475 has been marked as a duplicate of this bug. ***,*** Bug 69475 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"['*** Bug 69475 has been marked as a duplicate of this bug.', '***']",NA,0,*** Bug 69475 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, 18756,Login as another user no longer works,*** Bug 69475 has been marked as a duplicate of this bug. ***,1410978978,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,*** Bug 69475 has been marked as a duplicate of this bug. ***,*** Bug 69475 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"['*** Bug 69475 has been marked as a duplicate of this bug.', '***']",NA,0,***,NA,, 18757,Login as another user no longer works,"https://bugzilla.wikimedia.org/show_bug.cgi?id=49890 There was discussion on mailing lists about killing this behaviour.",1410848523,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"https://bugzilla.wikimedia.org/show_bug.cgi?id=49890 There was discussion on mailing lists about killing this behaviour.","URL There was discussion on mailing lists about killing this behaviour.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,['URL\n\nThere was discussion on mailing lists about killing this behaviour.'],NA,0,URL\n\nThere was discussion on mailing lists about killing this behaviour.,ISSUE CONTENT MANAGEMENT,, 18758,Login as another user no longer works,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",1410836467,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,","(In reply to Betacommand from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Betacommand from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI can assure you that MediaWiki core does not simultaneously log out all sessions.', 'All logging out does is clear your cookies.', 'I also just tested this on my Vagrant instance using two different browsers,']",NA,0,(In reply to Betacommand from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI can assure you that MediaWiki core does not simultaneously log out all sessions.,SOLUTION USAGE,, 18758,Login as another user no longer works,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",1410836467,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,","(In reply to Betacommand from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Betacommand from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI can assure you that MediaWiki core does not simultaneously log out all sessions.', 'All logging out does is clear your cookies.', 'I also just tested this on my Vagrant instance using two different browsers,']",NA,0,All logging out does is clear your cookies.,INVESTIGATION AND EXPLORATION,, 18758,Login as another user no longer works,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",1410836467,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Betacommand from comment #10) > Actually its not. That particular issue has existed for as long as I can > remember (~2006) If I log in via a bot, the cookies/session is kept and > reused as needed. If I then login via a web browser, both sessions work. > However if I log out via the web browser, the session/tokens that the bot > have been using get invalidated and cause the bot to no longer be logged in. > > That is about as core as one can get, prior to this a user could be logged > in as themselves, note their bot has a new message, log into the bot > account, clear the message, and then log back into the main account without > ever logging out. This enables multiple logins and does not cause issues > where the bot or user gets logged out on other devices/locations. I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,","(In reply to Betacommand from comment #10) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I can assure you that MediaWiki core does not simultaneously log out all sessions. All logging out does is clear your cookies. I also just tested this on my Vagrant instance using two different browsers,",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Betacommand from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI can assure you that MediaWiki core does not simultaneously log out all sessions.', 'All logging out does is clear your cookies.', 'I also just tested this on my Vagrant instance using two different browsers,']",NA,0,"I also just tested this on my Vagrant instance using two different browsers,",TESTING,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,Actually its not.,SOCIAL CONVERSATION,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,"That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.",INVESTIGATION AND EXPLORATION,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,"If I then login via a web browser, both sessions work.",BUG REPRODUCTION,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,"However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.",OBSERVED BUG BEHAVIOR,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,"That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.",WORKAROUND,, 18759,Login as another user no longer works,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",1410835565,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.","Actually its not. That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed. If I then login via a web browser, both sessions work. However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in. That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out. This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['Actually its not.', 'That particular issue has existed for as long as I can remember (~2006) If I log in via a bot, the cookies/session is kept and reused as needed.', 'If I then login via a web browser, both sessions work.', 'However if I log out via the web browser, the session/tokens that the bot have been using get invalidated and cause the bot to no longer be logged in.', 'That is about as core as one can get, prior to this a user could be logged in as themselves, note their bot has a new message, log into the bot account, clear the message, and then log back into the main account without ever logging out.', 'This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.']",NA,0,This enables multiple logins and does not cause issues where the bot or user gets logged out on other devices/locations.,SOLUTION DISCUSSION,, 18760,Login as another user no longer works,"(In reply to Betacommand from comment #8) > However logging out can cause problems because it invalidates all login > sessions. If a user is operating a bot and switches to remove the new > message talk page notice, it logs the bot out. That is CentralAuth, not a property of core.",1410835172,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Betacommand from comment #8) > However logging out can cause problems because it invalidates all login > sessions. If a user is operating a bot and switches to remove the new > message talk page notice, it logs the bot out. That is CentralAuth, not a property of core.","(In reply to Betacommand from comment #8) QUOTE QUOTE QUOTE That is CentralAuth, not a property of core.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Betacommand from comment #8)\nQUOTE\nQUOTE\nQUOTE\n\nThat is CentralAuth, not a property of core.']",NA,0,"(In reply to Betacommand from comment #8)\nQUOTE\nQUOTE\nQUOTE\n\nThat is CentralAuth, not a property of core.",INVESTIGATION AND EXPLORATION,, 18761,Login as another user no longer works,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",1410833881,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.","However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['However logging out can cause problems because it invalidates all login sessions.', 'If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out.', 'Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.']",NA,0,However logging out can cause problems because it invalidates all login sessions.,SOLUTION USAGE,, 18761,Login as another user no longer works,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",1410833881,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.","However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['However logging out can cause problems because it invalidates all login sessions.', 'If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out.', 'Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.']",NA,0,"If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out.",INVESTIGATION AND EXPLORATION,, 18761,Login as another user no longer works,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",1410833881,PHID-USER-jfiw563ca4r5mxfkj4vx,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.","However logging out can cause problems because it invalidates all login sessions. If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out. Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['However logging out can cause problems because it invalidates all login sessions.', 'If a user is operating a bot and switches to remove the new message talk page notice, it logs the bot out.', 'Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.']",NA,0,Honestly I think what this is fixing is a mole hill compared to the mountain of problems that it creates.,POTENTIAL NEW ISSUES AND REQUESTS,, 18762,Login as another user no longer works,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",1410833150,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.","(In reply to Bartosz Dziewo<77><6F>ski from comment #5) QUOTE QUOTE (In reply to Jon from comment #6) QUOTE QUOTE These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.', 'The only situation in which there would be no \'returnto\' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).', 'I feel like it is much easier and trivial to simply click Logout and then log back in again.', 'We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.']",NA,0,(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.,ISSUE CONTENT MANAGEMENT,, 18762,Login as another user no longer works,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",1410833150,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.","(In reply to Bartosz Dziewo<77><6F>ski from comment #5) QUOTE QUOTE (In reply to Jon from comment #6) QUOTE QUOTE These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.', 'The only situation in which there would be no \'returnto\' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).', 'I feel like it is much easier and trivial to simply click Logout and then log back in again.', 'We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.']",NA,0,The only situation in which there would be no \,SOCIAL CONVERSATION,, 18762,Login as another user no longer works,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",1410833150,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.","(In reply to Bartosz Dziewo<77><6F>ski from comment #5) QUOTE QUOTE (In reply to Jon from comment #6) QUOTE QUOTE These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.', 'The only situation in which there would be no \'returnto\' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).', 'I feel like it is much easier and trivial to simply click Logout and then log back in again.', 'We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.']",NA,0," parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).",SOLUTION DISCUSSION,, 18762,Login as another user no longer works,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",1410833150,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.","(In reply to Bartosz Dziewo<77><6F>ski from comment #5) QUOTE QUOTE (In reply to Jon from comment #6) QUOTE QUOTE These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.', 'The only situation in which there would be no \'returnto\' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).', 'I feel like it is much easier and trivial to simply click Logout and then log back in again.', 'We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.']",NA,0,I feel like it is much easier and trivial to simply click Logout and then log back in again.,WORKAROUND,, 18762,Login as another user no longer works,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",1410833150,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(In reply to Bartosz Dziewo<77><6F>ski from comment #5) > Indeed, but it should be easy enough to show the form instead of redirecting > when the user is logged in and there's no 'returnto' parameter. (In reply to Jon from comment #6) > To play devils advocate, why would you want to visit the login form whilst > logged in? What is wrong with logging out and then visiting it? These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.","(In reply to Bartosz Dziewo<77><6F>ski from comment #5) QUOTE QUOTE (In reply to Jon from comment #6) QUOTE QUOTE These two sort of go together. The only situation in which there would be no 'returnto' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar). I feel like it is much easier and trivial to simply click Logout and then log back in again. We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['(In reply to Bartosz Dziewo<77><6F>ski from comment #5)\nQUOTE\nQUOTE\n\n(In reply to Jon from comment #6)\nQUOTE\nQUOTE\n\nThese two sort of go together.', 'The only situation in which there would be no \'returnto\' parameter is if you manually navigated to the login page by typing ""Special:Userlogin"" in the search bar (or by entering it in your address bar).', 'I feel like it is much easier and trivial to simply click Logout and then log back in again.', 'We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.']",NA,0,"We might be able to improve the experience by having the logout page redirect back to the login page automatically, and just display a message saying you were logged out.",SOLUTION DISCUSSION,, 18763,Login as another user no longer works,"To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?",1410830348,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?","To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"['To play devils advocate, why would you want to visit the login form whilst logged in?', 'What is wrong with logging out and then visiting it?']",NA,0,"To play devils advocate, why would you want to visit the login form whilst logged in?",MOTIVATION,, 18763,Login as another user no longer works,"To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?",1410830348,PHID-USER-5dwuaigmkz2vzg65lape,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?","To play devils advocate, why would you want to visit the login form whilst logged in? What is wrong with logging out and then visiting it?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"['To play devils advocate, why would you want to visit the login form whilst logged in?', 'What is wrong with logging out and then visiting it?']",NA,0,What is wrong with logging out and then visiting it?,MOTIVATION,, 18764,Login as another user no longer works,"Indeed, but it should be easy enough to show the form instead of redirecting when the user is logged in and there's no 'returnto' parameter.",1410822782,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"Indeed, but it should be easy enough to show the form instead of redirecting when the user is logged in and there's no 'returnto' parameter.","Indeed, but it should be easy enough to show the form instead of redirecting when the user is logged in and there's no 'returnto' parameter.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"[""Indeed, but it should be easy enough to show the form instead of redirecting when the user is logged in and there's no 'returnto' parameter.""]",NA,0,"Indeed, but it should be easy enough to show the form instead of redirecting when the user is logged in and there's no 'returnto' parameter.",SOLUTION DISCUSSION,, 18765,Login as another user no longer works,"The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.",1410821550,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.","The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything.', 'IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.']",NA,0,"The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything.",SOLUTION DISCUSSION,, 18765,Login as another user no longer works,"The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.",1410821550,PHID-USER-ea6gwat27oulytc5tvsy,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.","The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything. IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['The issue fixed by the bug is pretty important, so simply reverting the patch will not actually solve anything.', 'IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.']",NA,0,"IMO, the bug described (switching between accounts) should really be solved by some sort of account switcher, e.g., like Google has.",SOLUTION DISCUSSION,, 18766,Login as another user no longer works,"(If this is fixed, 5dfc57eb80098a2016ed98cbdcca8ee6e1af1c79 should be reverted.)",1410820765,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"(If this is fixed, 5dfc57eb80098a2016ed98cbdcca8ee6e1af1c79 should be reverted.)","(If this is fixed, 5dfc57eb80098a2016ed98cbdcca8ee6e1af1c79 should be reverted.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,"['(If this is fixed, 5dfc57eb80098a2016ed98cbdcca8ee6e1af1c79 should be reverted.)']",NA,0,"(If this is fixed, 5dfc57eb80098a2016ed98cbdcca8ee6e1af1c79 should be reverted.)",SOLUTION DISCUSSION,, 18767,Login as another user no longer works,Caused by the fix for bug 15484: d0439af89f6b254cea09b3773ab139f04f81a97d.,1410820697,PHID-USER-wkpnidxoctuhawexig5p,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,Caused by the fix for bug 15484: d0439af89f6b254cea09b3773ab139f04f81a97d.,Caused by the fix for bug 15484: d0439af89f6b254cea09b3773ab139f04f81a97d.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-42,TRUE,['Caused by the fix for bug 15484: d0439af89f6b254cea09b3773ab139f04f81a97d.'],NA,0,Caused by the fix for bug 15484: d0439af89f6b254cea09b3773ab139f04f81a97d.,INVESTIGATION AND EXPLORATION,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,**swalling** wrote:\n\nThis is an odd regression.,SOCIAL CONVERSATION,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,For reproducibility:\n\n1.,BUG REPRODUCTION,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,Visit a wiki while logged in.,BUG REPRODUCTION,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,2,NA,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,Search for Special:UserLogin or enter in the URL manually.,INVESTIGATION AND EXPLORATION,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,3,NA,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,"You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.",EXPECTED BEHAVIOR,, 18768,Login as another user no longer works,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",1410808551,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-6mimi76qa47o25ubseql,task_subcomment,"**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.","**swalling** wrote: This is an odd regression. For reproducibility: 1. Visit a wiki while logged in. 2. Search for Special:UserLogin or enter in the URL manually. 3. You are redirected to the Main Page Expected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account. The form then tells you that you are already logged in and allows you to login as a separate user.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-42,TRUE,"['**swalling** wrote:\n\nThis is an odd regression.', 'For reproducibility:\n\n1.', 'Visit a wiki while logged in.', '2.', 'Search for Special:UserLogin or enter in the URL manually.', '3.', 'You are redirected to the Main Page\n\nExpected behavior: until recently, you should have been able to visit Special:UserLogin while authenticated as another account.', 'The form then tells you that you are already logged in and allows you to login as a separate user.']",NA,0,The form then tells you that you are already logged in and allows you to login as a separate user.,OBSERVED BUG BEHAVIOR,, 18874,Use returnto as redirect location after Login,"For now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",1404306480,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-xvgivdciq23cos4hmomy,task_description,"Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement","Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",High,80,1404376499,NA,resolved,TRUE,c3,1,TRUE,FALSE,-53,TRUE,"['Use returnto as redirect location after Login.', 'For now, after a login the user will be redirected to the Main page of the Wiki-project.', 'Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,Use returnto as redirect location after Login.,EXPECTED BEHAVIOR,, 18874,Use returnto as redirect location after Login,"For now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",1404306480,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-xvgivdciq23cos4hmomy,task_description,"Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement","Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",High,80,1404376499,NA,resolved,TRUE,c3,1,TRUE,FALSE,-53,TRUE,"['Use returnto as redirect location after Login.', 'For now, after a login the user will be redirected to the Main page of the Wiki-project.', 'Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,"For now, after a login the user will be redirected to the Main page of the Wiki-project.",OBSERVED BUG BEHAVIOR,, 18874,Use returnto as redirect location after Login,"For now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",1404306480,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-xvgivdciq23cos4hmomy,task_description,"Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement","Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",High,80,1404376499,NA,resolved,TRUE,c3,1,TRUE,FALSE,-53,TRUE,"['Use returnto as redirect location after Login.', 'For now, after a login the user will be redirected to the Main page of the Wiki-project.', 'Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,"Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.",SOLUTION DISCUSSION,, 18874,Use returnto as redirect location after Login,"For now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",1404306480,PHID-USER-c5xwrfdyp3dckkh2nkoj,PHID-TASK-xvgivdciq23cos4hmomy,task_description,"Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement","Use returnto as redirect location after Login./n/nFor now, after a login the user will be redirected to the Main page of the Wiki-project. Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function. -------------------------- **Version**: unspecified **Severity**: enhancement",High,80,1404376499,NA,resolved,TRUE,c3,1,TRUE,FALSE,-53,TRUE,"['Use returnto as redirect location after Login.', 'For now, after a login the user will be redirected to the Main page of the Wiki-project.', 'Save the returnto parameter of Loginpage and return to this location after successful login to be constistent with the ""normal"" login function.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, 18875,Use returnto as redirect location after Login,"Change 143633 merged by jenkins-bot: Add returnto redirect https://gerrit.wikimedia.org/r/143633",1404375473,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xvgivdciq23cos4hmomy,task_subcomment,"Change 143633 merged by jenkins-bot: Add returnto redirect https://gerrit.wikimedia.org/r/143633","Change 143633 merged by jenkins-bot: Add returnto redirect GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-52,TRUE,['Change 143633 merged by jenkins-bot:\nAdd returnto redirect\n\nGERRIT_URL'],NA,0,Change 143633 merged by jenkins-bot:\nAdd returnto redirect\n\nGERRIT_URL,TASK PROGRESS,, 18876,Use returnto as redirect location after Login,"Change 143633 had a related patch set uploaded by Florianschmidtwelzow: Add returnto redirect https://gerrit.wikimedia.org/r/143633",1404319142,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xvgivdciq23cos4hmomy,task_subcomment,"Change 143633 had a related patch set uploaded by Florianschmidtwelzow: Add returnto redirect https://gerrit.wikimedia.org/r/143633","Change 143633 had a related patch set uploaded by Florianschmidtwelzow: Add returnto redirect GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-53,TRUE,['Change 143633 had a related patch set uploaded by Florianschmidtwelzow:\nAdd returnto redirect\n\nGERRIT_URL'],NA,0,Change 143633 had a related patch set uploaded by Florianschmidtwelzow:\nAdd returnto redirect\n\nGERRIT_URL,TASK PROGRESS,, 18925,enable SSL/https support again,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",1396634940,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_description,"enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387","enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",High,80,1397720970,NA,resolved,TRUE,c3,1,TRUE,FALSE,-65,TRUE,"['enable SSL/https support again.', 'Please enable ssl/https support for the beta wikis again.', 'It is missing after migration to eqiad.', 'Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,enable SSL/https support again.,EXPECTED BEHAVIOR,, 18925,enable SSL/https support again,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",1396634940,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_description,"enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387","enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",High,80,1397720970,NA,resolved,TRUE,c3,1,TRUE,FALSE,-65,TRUE,"['enable SSL/https support again.', 'Please enable ssl/https support for the beta wikis again.', 'It is missing after migration to eqiad.', 'Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,Please enable ssl/https support for the beta wikis again.,EXPECTED BEHAVIOR,, 18925,enable SSL/https support again,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",1396634940,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_description,"enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387","enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",High,80,1397720970,NA,resolved,TRUE,c3,1,TRUE,FALSE,-65,TRUE,"['enable SSL/https support again.', 'Please enable ssl/https support for the beta wikis again.', 'It is missing after migration to eqiad.', 'Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,It is missing after migration to eqiad.,OBSERVED BUG BEHAVIOR,, 18925,enable SSL/https support again,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",1396634940,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_description,"enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387","enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",High,80,1397720970,NA,resolved,TRUE,c3,1,TRUE,FALSE,-65,TRUE,"['enable SSL/https support again.', 'Please enable ssl/https support for the beta wikis again.', 'It is missing after migration to eqiad.', 'Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,"Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.",SOLUTION DISCUSSION,, 18925,enable SSL/https support again,"Please enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387",1396634940,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_description,"enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=68387","enable SSL/https support again./n/nPlease enable ssl/https support for the beta wikis again. It is missing after migration to eqiad. Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok. see bug 48501 for task to get real beta certs but only for limited subdomains. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",High,80,1397720970,NA,resolved,TRUE,c3,1,TRUE,FALSE,-65,TRUE,"['enable SSL/https support again.', 'Please enable ssl/https support for the beta wikis again.', 'It is missing after migration to eqiad.', 'Btw: The old cert issued by Labs CA for all beta subdomains was not considered ""valid"" because among others things it was only for issued for *.wmflabs.org (counts only for direct subdomain) but thats ok.\nsee bug 48501 for task to get real beta certs but only for limited subdomains.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 18926,enable SSL/https support again,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,1397720970,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-63,TRUE,"['SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501.', 'There is no need to have two bugs to track the issue :-D']",NA,0,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501.,INVESTIGATION AND EXPLORATION,, 18926,enable SSL/https support again,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,1397720970,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501. There is no need to have two bugs to track the issue :-D,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-63,TRUE,"['SSL is enabled again but is not going to work until someone sort out the SSL certificate issue tracked by bug 48501.', 'There is no need to have two bugs to track the issue :-D']",NA,0,There is no need to have two bugs to track the issue :-D,ISSUE CONTENT MANAGEMENT,, 18927,enable SSL/https support again,"(In reply to se4598 from comment #6) appendix: even if the mentioned bug now covers that too, leave this bug open until it's somehow working, because of the dependencies/blocked bug of this etc.",1397671420,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"(In reply to se4598 from comment #6) appendix: even if the mentioned bug now covers that too, leave this bug open until it's somehow working, because of the dependencies/blocked bug of this etc.","(In reply to se4598 from comment #6) appendix: even if the mentioned bug now covers that too, leave this bug open until it's somehow working, because of the dependencies/blocked bug of this etc.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"[""(In reply to se4598 from comment #6)\nappendix: even if the mentioned bug now covers that too, leave this bug open until it's somehow working, because of the dependencies/blocked bug of this etc.""]",NA,0,"(In reply to se4598 from comment #6)\nappendix: even if the mentioned bug now covers that too, leave this bug open until it's somehow working, because of the dependencies/blocked bug of this etc.",ISSUE CONTENT MANAGEMENT,, 18928,enable SSL/https support again,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",1397670859,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?","REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['REOPEN: bug 48501 is about getting real, valid certs.', 'This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up).', ""I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains?"", ""Thats how it was and worked in pmtpa, so what's the problem here?""]",NA,0,"REOPEN: bug 48501 is about getting real, valid certs.",ACTION ON ISSUE ,, 18928,enable SSL/https support again,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",1397670859,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?","REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['REOPEN: bug 48501 is about getting real, valid certs.', 'This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up).', ""I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains?"", ""Thats how it was and worked in pmtpa, so what's the problem here?""]",NA,0,This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up).,ISSUE CONTENT MANAGEMENT,, 18928,enable SSL/https support again,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",1397670859,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?","REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['REOPEN: bug 48501 is about getting real, valid certs.', 'This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up).', ""I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains?"", ""Thats how it was and worked in pmtpa, so what's the problem here?""]",NA,0,"I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains?",SOLUTION DISCUSSION,, 18928,enable SSL/https support again,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",1397670859,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?","REOPEN: bug 48501 is about getting real, valid certs. This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up). I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains? Thats how it was and worked in pmtpa, so what's the problem here?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['REOPEN: bug 48501 is about getting real, valid certs.', 'This about accessing beta with https (regardless if the cert is valid for the browser and a warning message pops up).', ""I don't know nginx to say why he doesn't like the cert, but how about generating new, self-signed or by Labs CA for beta domains?"", ""Thats how it was and worked in pmtpa, so what's the problem here?""]",NA,0,"Thats how it was and worked in pmtpa, so what's the problem here?",INVESTIGATION AND EXPLORATION,, 18929,enable SSL/https support again,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,1397642933,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['The puppet class role::protoproxy::ssl::beta is applied on all varnish instances.', 'Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3).', 'That would be solved whenever we get certificates on beta which is the rather long bug 48501.']",NA,0,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances.,OBSERVED BUG BEHAVIOR,, 18929,enable SSL/https support again,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,1397642933,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['The puppet class role::protoproxy::ssl::beta is applied on all varnish instances.', 'Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3).', 'That would be solved whenever we get certificates on beta which is the rather long bug 48501.']",NA,0,Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3).,OBSERVED BUG BEHAVIOR,, 18929,enable SSL/https support again,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,1397642933,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,The puppet class role::protoproxy::ssl::beta is applied on all varnish instances. Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3). That would be solved whenever we get certificates on beta which is the rather long bug 48501.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-64,TRUE,"['The puppet class role::protoproxy::ssl::beta is applied on all varnish instances.', 'Nginx refuses to starts because the /etc/ssl/private/star.wmflabs.org.key key mismatch (see comment #3).', 'That would be solved whenever we get certificates on beta which is the rather long bug 48501.']",NA,0,That would be solved whenever we get certificates on beta which is the rather long bug 48501.,FUTURE PLANS,, 18930,enable SSL/https support again,"Change 124057 merged by Dzahn: beta: adjust protoproxy for eqiad https://gerrit.wikimedia.org/r/124057",1397636946,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"Change 124057 merged by Dzahn: beta: adjust protoproxy for eqiad https://gerrit.wikimedia.org/r/124057","Change 124057 merged by Dzahn: beta: adjust protoproxy for eqiad GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-64,TRUE,['Change 124057 merged by Dzahn:\nbeta: adjust protoproxy for eqiad\n\nGERRIT_URL'],NA,0,Change 124057 merged by Dzahn:\nbeta: adjust protoproxy for eqiad\n\nGERRIT_URL,TASK PROGRESS,, 18931,enable SSL/https support again,"While applying the puppet class on deployment-cache-bits01, nginx ends up bailing out with: root@deployment-cache-bits01:~# /etc/init.d/nginx start Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file(""/etc/ssl/private/star.wmflabs.org.key"") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch) nginx: configuration file /etc/nginx/nginx.conf test failed",1396865586,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"While applying the puppet class on deployment-cache-bits01, nginx ends up bailing out with: root@deployment-cache-bits01:~# /etc/init.d/nginx start Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file(""/etc/ssl/private/star.wmflabs.org.key"") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch) nginx: configuration file /etc/nginx/nginx.conf test failed","While applying the puppet class on deployment-cache-bits01, nginx ends up bailing out with: root@deployment-cache-bits01:~# /etc/init.d/nginx start Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file(""/etc/ssl/private/star.wmflabs.org.key"") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch) nginx: configuration file /etc/nginx/nginx.conf test failed",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-65,TRUE,"['While applying the puppet class on deployment-cache-bits01, nginx ends up bailing out with:\n\n root@deployment-cache-bits01:~# /etc/init.d/nginx start\n Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file(""/etc/ssl/private/star.wmflabs.org.key"") failed\n (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)\n nginx: configuration file /etc/nginx/nginx.conf test failed']",NA,0,"While applying the puppet class on deployment-cache-bits01, nginx ends up bailing out with:\n\n root@deployment-cache-bits01:~# /etc/init.d/nginx start\n Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file(""/etc/ssl/private/star.wmflabs.org.key"") failed\n (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)\n nginx: configuration file /etc/nginx/nginx.conf test failed",OBSERVED BUG BEHAVIOR,, 18932,enable SSL/https support again,"Patch is there, will get it fixed this afternoon hopefully :-]",1396693634,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"Patch is there, will get it fixed this afternoon hopefully :-]","Patch is there, will get it fixed this afternoon hopefully :-]",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-65,TRUE,"['Patch is there, will get it fixed this afternoon hopefully :-]']",NA,0,"Patch is there, will get it fixed this afternoon hopefully :-]",TASK PROGRESS,, 18933,enable SSL/https support again,"Change 124057 had a related patch set uploaded by Hashar: beta: adjust protoproxy for eqiad https://gerrit.wikimedia.org/r/124057",1396693598,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-zil3dzudm6lc65b24rkh,task_subcomment,"Change 124057 had a related patch set uploaded by Hashar: beta: adjust protoproxy for eqiad https://gerrit.wikimedia.org/r/124057","Change 124057 had a related patch set uploaded by Hashar: beta: adjust protoproxy for eqiad GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-65,TRUE,['Change 124057 had a related patch set uploaded by Hashar:\nbeta: adjust protoproxy for eqiad\n\nGERRIT_URL'],NA,0,Change 124057 had a related patch set uploaded by Hashar:\nbeta: adjust protoproxy for eqiad\n\nGERRIT_URL,TASK PROGRESS,, 19288,Wikitech signup page displays <loginstart> and <loginend>,"[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",1414822440,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_description,"Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial","Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",Medium,50,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,1,TRUE,FALSE,-35,TRUE,"['Wikitech signup page displays <loginstart> and <loginend>.', '[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.', ""[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell."", '<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.', '--------------------------\n**Version**: unspecified\n**Severity**: trivial']",TRUE,0,Wikitech signup page displays <loginstart> and <loginend>.,OBSERVED BUG BEHAVIOR,, 19288,Wikitech signup page displays <loginstart> and <loginend>,"[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",1414822440,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_description,"Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial","Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",Medium,50,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,1,TRUE,FALSE,-35,TRUE,"['Wikitech signup page displays <loginstart> and <loginend>.', '[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.', ""[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell."", '<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.', '--------------------------\n**Version**: unspecified\n**Severity**: trivial']",TRUE,0,"[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.",OBSERVED BUG BEHAVIOR,, 19288,Wikitech signup page displays <loginstart> and <loginend>,"[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",1414822440,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_description,"Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial","Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",Medium,50,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,1,TRUE,FALSE,-35,TRUE,"['Wikitech signup page displays <loginstart> and <loginend>.', '[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.', ""[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell."", '<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.', '--------------------------\n**Version**: unspecified\n**Severity**: trivial']",TRUE,0,<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.,EXPECTED BEHAVIOR,, 19288,Wikitech signup page displays <loginstart> and <loginend>,"[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",1414822440,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_description,"Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial","Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",Medium,50,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,1,TRUE,FALSE,-35,TRUE,"['Wikitech signup page displays <loginstart> and <loginend>.', '[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.', ""[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell."", '<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.', '--------------------------\n**Version**: unspecified\n**Severity**: trivial']",TRUE,0,--------------------------\n**Version**: unspecified\n**Severity**: trivial,OBSERVED BUG BEHAVIOR,, 19288,Wikitech signup page displays <loginstart> and <loginend>,"[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",1414822440,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_description,"Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial","Wikitech signup page displays <loginstart> and <loginend>./n/n[[wikitech:Special:UserLogin/signup]] contains the following text: ---- <loginstart> By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org. [...] If that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell. <loginend> ---- The <loginstart> and <loginend> placeholders should not be visible. -------------------------- **Version**: unspecified **Severity**: trivial",Medium,50,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,1,TRUE,FALSE,-35,TRUE,"['Wikitech signup page displays <loginstart> and <loginend>.', '[[wikitech:Special:UserLogin/signup]] contains the following text:\n\n----\n\n<loginstart> \n\n By creating an account in this project and/or using other wmflabs.org Services, you agree to comply with the Terms of Use for wmflabs.org.', ""[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell."", '<loginend>\n\n----\n\nThe <loginstart> and <loginend> placeholders should not be visible.', '--------------------------\n**Version**: unspecified\n**Severity**: trivial']",TRUE,0,"[...]\n\nIf that's not the case, ask someone to verify from a labs instance whether the shell username is taken, by issuing the command groups $username on a shell.",SOLUTION DISCUSSION,, 19289,Wikitech signup page displays <loginstart> and <loginend>,I've removed the singupstart and signupend templates.,1433868248,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,I've removed the singupstart and signupend templates.,I've removed the singupstart and signupend templates.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""I've removed the singupstart and signupend templates.""]",NA,0,I've removed the singupstart and signupend templates.,SOLUTION DISCUSSION,, 19290,Wikitech signup page displays <loginstart> and <loginend>,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",1415482419,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).","IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['IMHO, you can drop it.', 'Signupstart is intended to be an extra message.', 'If defined, it adds the following block to the code, before the #userloginForm element:\n\n <div id=""signupstart"">Content of Signupstart message</div>\n\nThe same applies for Signupend, it\'s added in the userloginForm, after the form and before the closing div.', '<div id=""signupend"">Content of Signupend message</div>\n\nReference: mediawiki/core, includes/templates/Usercreate.php\n\n[On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).']",NA,0,"IMHO, you can drop it.",SOLUTION DISCUSSION,, 19290,Wikitech signup page displays <loginstart> and <loginend>,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",1415482419,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).","IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['IMHO, you can drop it.', 'Signupstart is intended to be an extra message.', 'If defined, it adds the following block to the code, before the #userloginForm element:\n\n <div id=""signupstart"">Content of Signupstart message</div>\n\nThe same applies for Signupend, it\'s added in the userloginForm, after the form and before the closing div.', '<div id=""signupend"">Content of Signupend message</div>\n\nReference: mediawiki/core, includes/templates/Usercreate.php\n\n[On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).']",NA,0,Signupstart is intended to be an extra message.,EXPECTED BEHAVIOR,, 19290,Wikitech signup page displays <loginstart> and <loginend>,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",1415482419,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).","IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['IMHO, you can drop it.', 'Signupstart is intended to be an extra message.', 'If defined, it adds the following block to the code, before the #userloginForm element:\n\n <div id=""signupstart"">Content of Signupstart message</div>\n\nThe same applies for Signupend, it\'s added in the userloginForm, after the form and before the closing div.', '<div id=""signupend"">Content of Signupend message</div>\n\nReference: mediawiki/core, includes/templates/Usercreate.php\n\n[On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).']",NA,0,"If defined, it adds the following block to the code, before the #userloginForm element:\n\n <div id=""signupstart"">Content of Signupstart message</div>\n\nThe same applies for Signupend, it\",SOLUTION DISCUSSION,, 19290,Wikitech signup page displays <loginstart> and <loginend>,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",1415482419,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).","IMHO, you can drop it. Signupstart is intended to be an extra message. If defined, it adds the following block to the code, before the #userloginForm element: <div id=""signupstart"">Content of Signupstart message</div> The same applies for Signupend, it's added in the userloginForm, after the form and before the closing div. <div id=""signupend"">Content of Signupend message</div> Reference: mediawiki/core, includes/templates/Usercreate.php [On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['IMHO, you can drop it.', 'Signupstart is intended to be an extra message.', 'If defined, it adds the following block to the code, before the #userloginForm element:\n\n <div id=""signupstart"">Content of Signupstart message</div>\n\nThe same applies for Signupend, it\'s added in the userloginForm, after the form and before the closing div.', '<div id=""signupend"">Content of Signupend message</div>\n\nReference: mediawiki/core, includes/templates/Usercreate.php\n\n[On a side note, feel free to open another bug to give them better names: the first is an extra introductio before the form, the second is an extra place inside the form).']",NA,0,signupend,NA,, 19291,Wikitech signup page displays <loginstart> and <loginend>,"I'm happy to fix this, but I'm with Tim -- not yet clear on what the proper solution is.",1415459744,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"I'm happy to fix this, but I'm with Tim -- not yet clear on what the proper solution is.","I'm happy to fix this, but I'm with Tim -- not yet clear on what the proper solution is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"[""I'm happy to fix this, but I'm with Tim -- not yet clear on what the proper solution is.""]",NA,0,"I'm happy to fix this, but I'm with Tim -- not yet clear on what the proper solution is.",CONTRIBUTION AND COMMITMENT,, 19292,Wikitech signup page displays <loginstart> and <loginend>,"(Not being a sysop, just curious: Does this mean that ""{{int:loginstart}}"" should be removed from [[wikitech:MediaWiki:Signupstart]], or that [[wikitech:MediaWiki:Loginstart]] needs to be created?)",1415455890,PHID-USER-vk6mlmacfhx77egryy5i,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"(Not being a sysop, just curious: Does this mean that ""{{int:loginstart}}"" should be removed from [[wikitech:MediaWiki:Signupstart]], or that [[wikitech:MediaWiki:Loginstart]] needs to be created?)","(Not being a sysop, just curious: Does this mean that ""{{int:loginstart}}"" should be removed from [[wikitech:MediaWiki:Signupstart]], or that [[wikitech:MediaWiki:Loginstart]] needs to be created?)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['(Not being a sysop, just curious: Does this mean that ""{{int:loginstart}}"" should be removed from [[wikitech:MediaWiki:Signupstart]], or that [[wikitech:MediaWiki:Loginstart]] needs to be created?)']",NA,0,"(Not being a sysop, just curious: Does this mean that ""{{int:loginstart}}"" should be removed from [[wikitech:MediaWiki:Signupstart]], or that [[wikitech:MediaWiki:Loginstart]] needs to be created?)",INVESTIGATION AND EXPLORATION,, 19293,Wikitech signup page displays <loginstart> and <loginend>,"(In reply to Dereckson from comment #2) > Could you contact a sysop from this list about this issue? > https://wikitech.wikimedia.org/w/index. > php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50 A number of them got automatically CC'd onto this bug, so I wonder if one of them could take a moment to fix this?",1415436725,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"(In reply to Dereckson from comment #2) > Could you contact a sysop from this list about this issue? > https://wikitech.wikimedia.org/w/index. > php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50 A number of them got automatically CC'd onto this bug, so I wonder if one of them could take a moment to fix this?","(In reply to Dereckson from comment #2) QUOTE QUOTE QUOTE A number of them got automatically CC'd onto this bug, so I wonder if one of them could take a moment to fix this?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"[""(In reply to Dereckson from comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nA number of them got automatically CC'd onto this bug, so I wonder if one of them could take a moment to fix this?""]",NA,0,"(In reply to Dereckson from comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nA number of them got automatically CC'd onto this bug, so I wonder if one of them could take a moment to fix this?",CONTRIBUTION AND COMMITMENT,, 19294,Wikitech signup page displays <loginstart> and <loginend>,Could you contact a sysop from this list about this issue? https://wikitech.wikimedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50,1415410102,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,Could you contact a sysop from this list about this issue? https://wikitech.wikimedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50,Could you contact a sysop from this list about this issue? URL,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['Could you contact a sysop from this list about this issue?', 'URL']",NA,0,Could you contact a sysop from this list about this issue?,CONTRIBUTION AND COMMITMENT,, 19294,Wikitech signup page displays <loginstart> and <loginend>,Could you contact a sysop from this list about this issue? https://wikitech.wikimedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50,1415410102,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,Could you contact a sysop from this list about this issue? https://wikitech.wikimedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&editsOnly=1&limit=50,Could you contact a sysop from this list about this issue? URL,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['Could you contact a sysop from this list about this issue?', 'URL']",NA,0,URL,NA,, 19295,Wikitech signup page displays <loginstart> and <loginend>,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",1415409906,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.","This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is a problem directly solvable on the wiki.', 'The system messages concerned is signupstart.', 'And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.', 'When through ULS I switched from qqx back to en, I got a regular English message.', ""So yes, it's well an issue with the local message.""]",NA,0,This is a problem directly solvable on the wiki.,WORKAROUND,, 19295,Wikitech signup page displays <loginstart> and <loginend>,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",1415409906,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.","This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is a problem directly solvable on the wiki.', 'The system messages concerned is signupstart.', 'And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.', 'When through ULS I switched from qqx back to en, I got a regular English message.', ""So yes, it's well an issue with the local message.""]",NA,0,The system messages concerned is signupstart.,INVESTIGATION AND EXPLORATION,, 19295,Wikitech signup page displays <loginstart> and <loginend>,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",1415409906,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.","This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is a problem directly solvable on the wiki.', 'The system messages concerned is signupstart.', 'And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.', 'When through ULS I switched from qqx back to en, I got a regular English message.', ""So yes, it's well an issue with the local message.""]",NA,0,And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.,INVESTIGATION AND EXPLORATION,, 19295,Wikitech signup page displays <loginstart> and <loginend>,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",1415409906,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.","This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is a problem directly solvable on the wiki.', 'The system messages concerned is signupstart.', 'And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.', 'When through ULS I switched from qqx back to en, I got a regular English message.', ""So yes, it's well an issue with the local message.""]",NA,0,"When through ULS I switched from qqx back to en, I got a regular English message.",BUG REPRODUCTION,, 19295,Wikitech signup page displays <loginstart> and <loginend>,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",1415409906,PHID-USER-4opnqejtv7adgswtxy67,PHID-TASK-ovsa4swrphzdhhychn3j,task_subcomment,"This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.","This is a problem directly solvable on the wiki. The system messages concerned is signupstart. And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}. When through ULS I switched from qqx back to en, I got a regular English message. So yes, it's well an issue with the local message.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is a problem directly solvable on the wiki.', 'The system messages concerned is signupstart.', 'And indeed [[wikitech:MediaWiki:Signupstart]] start with {{int:loginstart}}.', 'When through ULS I switched from qqx back to en, I got a regular English message.', ""So yes, it's well an issue with the local message.""]",NA,0,"So yes, it's well an issue with the local message.",INVESTIGATION AND EXPLORATION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.",OBSERVED BUG BEHAVIOR,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"It may be affecting all mobile devices, or maybe just Safari; not sure.",BUG REPRODUCTION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Steps to repro:\n\n1.,BUG REPRODUCTION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.",BUG REPRODUCTION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,2,NA,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Go to login page and enter username/pw.,BUG REPRODUCTION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Tap login.,NA,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,You\,NA,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2).,BUG REPRODUCTION,, 19396,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079",1409268780,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_description,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=71079","Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster./n/nI've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a ""Safari cannot open page because it could not connect to the server"" page. Makes testing new mobile features very difficult :( -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,TRUE,FALSE,-44,TRUE,"['Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster.', ""I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2)."", 'It may be affecting all mobile devices, or maybe just Safari; not sure.', 'Steps to repro:\n\n1.', 'On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email.', '2.', 'Go to login page and enter username/pw.', 'Tap login.', 'You\'ll get taken to a ""Safari cannot open page because it could not connect to the server"" page.', 'Makes testing new mobile features very difficult :(\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Safari cannot open page because it could not connect to the server,OBSERVED BUG BEHAVIOR,, 19397,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",@greg: I can confirm this bug is still occurring.,1419376965,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,@greg: I can confirm this bug is still occurring.,SCREEN_NAME: I can confirm this bug is still occurring.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-28,TRUE,['SCREEN_NAME: I can confirm this bug is still occurring.'],NA,0,SCREEN_NAME: I can confirm this bug is still occurring.,BUG REPRODUCTION,, 19398,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",1416872272,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""I've tripped on this problem a couple times in the last week again myself."", ""I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta."", 'This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.', ""It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint."", '(Or get TLS setup for beta: {T70387})']",NA,0,This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.,OBSERVED BUG BEHAVIOR,, 19398,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",1416872272,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""I've tripped on this problem a couple times in the last week again myself."", ""I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta."", 'This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.', ""It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint."", '(Or get TLS setup for beta: {T70387})']",NA,0,(Or get TLS setup for beta: {T70387}),POTENTIAL NEW ISSUES AND REQUESTS,, 19398,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",1416872272,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""I've tripped on this problem a couple times in the last week again myself."", ""I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta."", 'This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.', ""It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint."", '(Or get TLS setup for beta: {T70387})']",NA,0,I've tripped on this problem a couple times in the last week again myself.,BUG REPRODUCTION,, 19398,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",1416872272,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""I've tripped on this problem a couple times in the last week again myself."", ""I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta."", 'This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.', ""It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint."", '(Or get TLS setup for beta: {T70387})']",NA,0,I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta.,BUG REPRODUCTION,, 19398,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",1416872272,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to https://... and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})","I've tripped on this problem a couple times in the last week again myself. I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta. This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites. It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint. (Or get TLS setup for beta: {T70387})",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""I've tripped on this problem a couple times in the last week again myself."", ""I'm using Chrome and have seen the forceHTTPS=1 cookie end up set when logging in to beta."", 'This results in failed attempts to connect to URL and then needs me to clear the cookie to get back to looking at beta sites.', ""It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint."", '(Or get TLS setup for beta: {T70387})']",NA,0,It would be nice to be able to ignore the cookie entirely in environments like beta where we actually don't have a TLS endpoint.,SOLUTION DISCUSSION,, 19399,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",">>! In T72145#730119, @csteipp wrote: > On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. > > The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https. Assuming this is still the case (Kaldari: can you confirm?), let's try that route.",1416871876,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,">>! In T72145#730119, @csteipp wrote: > On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. > > The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https. Assuming this is still the case (Kaldari: can you confirm?), let's try that route.","QUOTE QUOTE QUOTE QUOTE Assuming this is still the case (Kaldari: can you confirm?), let's try that route.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAssuming this is still the case (Kaldari: can you confirm?', ""), let's try that route.""]",NA,0,QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAssuming this is still the case (Kaldari: can you confirm?,INVESTIGATION AND EXPLORATION,, 19399,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",">>! In T72145#730119, @csteipp wrote: > On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. > > The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https. Assuming this is still the case (Kaldari: can you confirm?), let's try that route.",1416871876,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,">>! In T72145#730119, @csteipp wrote: > On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. > > The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https. Assuming this is still the case (Kaldari: can you confirm?), let's try that route.","QUOTE QUOTE QUOTE QUOTE Assuming this is still the case (Kaldari: can you confirm?), let's try that route.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAssuming this is still the case (Kaldari: can you confirm?', ""), let's try that route.""]",NA,0,"), let's try that route.",SOLUTION DISCUSSION,, 19400,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",Is this still 'unbreak now'?,1416833965,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,Is this still 'unbreak now'?,Is this still 'unbreak now'?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-32,TRUE,"[""Is this still 'unbreak now'?""]",NA,0,Is this still 'unbreak now'?,ISSUE CONTENT MANAGEMENT,, 19401,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",1409788557,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.","(In reply to Dan Duvall from comment #22) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Dan Duvall from comment #22)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that's all correct."", 'On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.', 'The check could ensure that the cookie value isn\'t ""deleted"", since we set it to 1 when we want users to stay in https.']",NA,0,"On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.",OBSERVED BUG BEHAVIOR,, 19401,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",1409788557,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.","(In reply to Dan Duvall from comment #22) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Dan Duvall from comment #22)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that's all correct."", 'On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.', 'The check could ensure that the cookie value isn\'t ""deleted"", since we set it to 1 when we want users to stay in https.']",NA,0,The check could ensure that the cookie value isn\,SOLUTION DISCUSSION,, 19401,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",1409788557,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.","(In reply to Dan Duvall from comment #22) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Dan Duvall from comment #22)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that's all correct."", 'On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.', 'The check could ensure that the cookie value isn\'t ""deleted"", since we set it to 1 when we want users to stay in https.']",NA,0,"(In reply to Dan Duvall from comment #22)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that's all correct.",SOCIAL CONVERSATION,, 19401,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",1409788557,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal ""deleted"" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.","(In reply to Dan Duvall from comment #22) QUOTE QUOTE QUOTE QUOTE QUOTE Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't ""deleted"", since we set it to 1 when we want users to stay in https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Dan Duvall from comment #22)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that's all correct."", 'On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https.', 'The check could ensure that the cookie value isn\'t ""deleted"", since we set it to 1 when we want users to stay in https.']",NA,0,deleted,ACTION ON ISSUE,, 19402,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",1409786592,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""Chris, I've attached the tcpflow logs from our troubleshooting session."", ""Let me know if there's anything else that would be helpful."", 'A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\'s behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie.', 'The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.']",NA,0,"A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\",OBSERVED BUG BEHAVIOR,, 19402,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",1409786592,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""Chris, I've attached the tcpflow logs from our troubleshooting session."", ""Let me know if there's anything else that would be helpful."", 'A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\'s behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie.', 'The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.']",NA,0,"Chris, I've attached the tcpflow logs from our troubleshooting session.",ISSUE CONTENT MANAGEMENT,, 19402,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",1409786592,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""Chris, I've attached the tcpflow logs from our troubleshooting session."", ""Let me know if there's anything else that would be helpful."", 'A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\'s behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie.', 'The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.']",NA,0,Let me know if there's anything else that would be helpful.,SOCIAL CONVERSATION,, 19402,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",1409786592,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""Chris, I've attached the tcpflow logs from our troubleshooting session."", ""Let me know if there's anything else that would be helpful."", 'A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\'s behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie.', 'The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.']",NA,0,forceHTTPS=deleted,NA,, 19402,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",1409786592,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.","Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""Chris, I've attached the tcpflow logs from our troubleshooting session."", ""Let me know if there's anything else that would be helpful."", 'A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari\'s behavior seems intermittently incorrect in that it includes the ""forceHTTPS=deleted"" cookie in requests following the explicit expiration of the cookie.', 'The subsequent submission of the literal ""deleted"" cookie value causes a redirect to https.']",NA,0,deleted,ACTION ON ISSUE,, 19403,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Created attachment 16357 tcpflow log of successful login attempt in Safari (no redirect to https) **Attached**: {F14420}",1409786257,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Created attachment 16357 tcpflow log of successful login attempt in Safari (no redirect to https) **Attached**: {F14420}","Created attachment 16357 tcpflow log of successful login attempt in Safari (no redirect to https) **Attached**: {F14420}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,['Created attachment 16357\ntcpflow log of successful login attempt in Safari (no redirect to https)\n\n**Attached**: {F14420}'],NA,0,Created attachment 16357\ntcpflow log of successful login attempt in Safari (no redirect to https)\n\n**Attached**: {F14420},ISSUE CONTENT MANAGEMENT,, 19404,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Created attachment 16356 tcpflow log of successful login attempt in Safari (redirected to https) //attachment safari-beta-login-pcap-success.log ignored as obsolete//",1409786215,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Created attachment 16356 tcpflow log of successful login attempt in Safari (redirected to https) //attachment safari-beta-login-pcap-success.log ignored as obsolete//","Created attachment 16356 tcpflow log of successful login attempt in Safari (redirected to https) //attachment safari-beta-login-pcap-success.log ignored as obsolete//",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,['Created attachment 16356\ntcpflow log of successful login attempt in Safari (redirected to https)\n\n//attachment safari-beta-login-pcap-success.log ignored as obsolete//'],NA,0,Created attachment 16356\ntcpflow log of successful login attempt in Safari (redirected to https)\n\n//attachment safari-beta-login-pcap-success.log ignored as obsolete//,ISSUE CONTENT MANAGEMENT,, 19405,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Created attachment 16355 tcpflow log of failed login attempt in Safari (redirected to https) **Attached**: {F14419}",1409786184,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Created attachment 16355 tcpflow log of failed login attempt in Safari (redirected to https) **Attached**: {F14419}","Created attachment 16355 tcpflow log of failed login attempt in Safari (redirected to https) **Attached**: {F14419}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,['Created attachment 16355\ntcpflow log of failed login attempt in Safari (redirected to https)\n\n**Attached**: {F14419}'],NA,0,Created attachment 16355\ntcpflow log of failed login attempt in Safari (redirected to https)\n\n**Attached**: {F14419},ISSUE CONTENT MANAGEMENT,, 19406,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...",1409766836,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: URL ...",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""For me, it's redirecting to https on the final CA login redirect."", 'Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in.', 'GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2\n ...\n\n\n HTTP/1.1 302 forced.302\n Location: URL\n ...']",NA,0,Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in.,OBSERVED BUG BEHAVIOR,, 19406,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...",1409766836,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: URL ...",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""For me, it's redirecting to https on the final CA login redirect."", 'Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in.', 'GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2\n ...\n\n\n HTTP/1.1 302 forced.302\n Location: URL\n ...']",NA,0,"GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2\n ...\n\n\n HTTP/1.1 302 forced.302\n Location: URL\n ...",OBSERVED BUG BEHAVIOR,, 19406,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...",1409766836,PHID-USER-7bifphmxtcqgvdofuzla,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...","For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: URL ...",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""For me, it's redirecting to https on the final CA login redirect."", 'Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in.', 'GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2\n ...\n\n\n HTTP/1.1 302 forced.302\n Location: URL\n ...']",NA,0,"For me, it's redirecting to https on the final CA login redirect.",OBSERVED BUG BEHAVIOR,, 19407,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",1409765302,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.","(In reply to Ryan Kaldari from comment #10) QUOTE QUOTE QUOTE QUOTE If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Ryan Kaldari from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIf it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header."", 'That, or Safari thinks it should always use ssl.', ""We've never sent hsts headers for that domain."", ""I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.""]",NA,0,"That, or Safari thinks it should always use ssl.",INVESTIGATION AND EXPLORATION,, 19407,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",1409765302,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.","(In reply to Ryan Kaldari from comment #10) QUOTE QUOTE QUOTE QUOTE If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Ryan Kaldari from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIf it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header."", 'That, or Safari thinks it should always use ssl.', ""We've never sent hsts headers for that domain."", ""I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.""]",NA,0,"(In reply to Ryan Kaldari from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIf it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header.",INVESTIGATION AND EXPLORATION,, 19407,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",1409765302,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.","(In reply to Ryan Kaldari from comment #10) QUOTE QUOTE QUOTE QUOTE If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Ryan Kaldari from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIf it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header."", 'That, or Safari thinks it should always use ssl.', ""We've never sent hsts headers for that domain."", ""I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.""]",NA,0,We've never sent hsts headers for that domain.,INVESTIGATION AND EXPLORATION,, 19407,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",1409765302,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.","(In reply to Ryan Kaldari from comment #10) QUOTE QUOTE QUOTE QUOTE If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""(In reply to Ryan Kaldari from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIf it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header."", 'That, or Safari thinks it should always use ssl.', ""We've never sent hsts headers for that domain."", ""I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.""]",NA,0,"I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.",INVESTIGATION AND EXPLORATION,, 19408,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,1409764873,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['My Safari is also stock.', 'It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from).', ""I've seen it fail on both.""]",NA,0,My Safari is also stock.,BUG REPRODUCTION,, 19408,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,1409764873,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['My Safari is also stock.', 'It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from).', ""I've seen it fail on both.""]",NA,0,It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from).,OBSERVED BUG BEHAVIOR,, 19408,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,1409764873,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['My Safari is also stock.', 'It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from).', ""I've seen it fail on both.""]",NA,0,I've seen it fail on both.,OBSERVED BUG BEHAVIOR,, 19409,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?,1409759635,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?,Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,['Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?'],NA,0,Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?,INVESTIGATION AND EXPLORATION,, 19410,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Maryana Pinchuk from comment #0) > You'll get taken to a ""Safari cannot open page because it could not connect > to the server"" page. Makes testing new mobile features very difficult :( My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(",1409759251,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Maryana Pinchuk from comment #0) > You'll get taken to a ""Safari cannot open page because it could not connect > to the server"" page. Makes testing new mobile features very difficult :( My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(","(In reply to Maryana Pinchuk from comment #0) QUOTE QUOTE My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['(In reply to Maryana Pinchuk from comment #0)\nQUOTE\nQUOTE\n\nMy stock install of Safari on my laptop also had this problem on my first try logging in to beta labs.', ':-(']",NA,0,(In reply to Maryana Pinchuk from comment #0)\nQUOTE\nQUOTE\n\nMy stock install of Safari on my laptop also had this problem on my first try logging in to beta labs.,BUG REPRODUCTION,, 19410,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Maryana Pinchuk from comment #0) > You'll get taken to a ""Safari cannot open page because it could not connect > to the server"" page. Makes testing new mobile features very difficult :( My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(",1409759251,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Maryana Pinchuk from comment #0) > You'll get taken to a ""Safari cannot open page because it could not connect > to the server"" page. Makes testing new mobile features very difficult :( My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(","(In reply to Maryana Pinchuk from comment #0) QUOTE QUOTE My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['(In reply to Maryana Pinchuk from comment #0)\nQUOTE\nQUOTE\n\nMy stock install of Safari on my laptop also had this problem on my first try logging in to beta labs.', ':-(']",NA,0,:-(,SOCIAL CONVERSATION,, 19411,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)",1409758673,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)","(In reply to Greg Grossmeier from comment #12) QUOTE I think my Safari is completely stock. I never use it because Safari. :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['(In reply to Greg Grossmeier from comment #12)\nQUOTE\n\nI think my Safari is completely stock.', 'I never use it because Safari.', ':)']",NA,0,(In reply to Greg Grossmeier from comment #12)\nQUOTE\n\nI think my Safari is completely stock.,BUG REPRODUCTION,, 19411,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)",1409758673,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)","(In reply to Greg Grossmeier from comment #12) QUOTE I think my Safari is completely stock. I never use it because Safari. :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['(In reply to Greg Grossmeier from comment #12)\nQUOTE\n\nI think my Safari is completely stock.', 'I never use it because Safari.', ':)']",NA,0,I never use it because Safari.,SOCIAL CONVERSATION,, 19411,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)",1409758673,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)","(In reply to Greg Grossmeier from comment #12) QUOTE I think my Safari is completely stock. I never use it because Safari. :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['(In reply to Greg Grossmeier from comment #12)\nQUOTE\n\nI think my Safari is completely stock.', 'I never use it because Safari.', ':)']",NA,0,:),SOCIAL CONVERSATION,, 19412,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Obvious question: SSL Everywhere installed? If so, tried disabling?",1409758297,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Obvious question: SSL Everywhere installed? If so, tried disabling?","Obvious question: SSL Everywhere installed? If so, tried disabling?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Obvious question: SSL Everywhere installed?', 'If so, tried disabling?']",NA,0,Obvious question: SSL Everywhere installed?,INVESTIGATION AND EXPLORATION,, 19412,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Obvious question: SSL Everywhere installed? If so, tried disabling?",1409758297,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Obvious question: SSL Everywhere installed? If so, tried disabling?","Obvious question: SSL Everywhere installed? If so, tried disabling?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Obvious question: SSL Everywhere installed?', 'If so, tried disabling?']",NA,0,"If so, tried disabling?",WORKAROUND,, 19413,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I'm seeing the same behavior as Bryan, it's trying to redirect to https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page which is failing.",1409704355,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I'm seeing the same behavior as Bryan, it's trying to redirect to https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page which is failing.","I'm seeing the same behavior as Bryan, it's trying to redirect to URL which is failing.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"[""I'm seeing the same behavior as Bryan, it's trying to redirect to URL which is failing.""]",NA,0,"I'm seeing the same behavior as Bryan, it's trying to redirect to URL which is failing.",OBSERVED BUG BEHAVIOR,, 19414,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","On a totally reset installation of Safari going to... http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin ... and logging in sporadically fails for me on both desktop and mobile Safari.",1409704165,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"On a totally reset installation of Safari going to... http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin ... and logging in sporadically fails for me on both desktop and mobile Safari.","On a totally reset installation of Safari going to... URL ... and logging in sporadically fails for me on both desktop and mobile Safari.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,['On a totally reset installation of Safari going to...\nURL\n... and logging in sporadically fails for me on both desktop and mobile Safari.'],NA,0,On a totally reset installation of Safari going to...\nURL\n... and logging in sporadically fails for me on both desktop and mobile Safari.,BUG REPRODUCTION,, 19415,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): https://bugzilla.wikimedia.org/show_bug.cgi?id=68387,1409703382,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): https://bugzilla.wikimedia.org/show_bug.cgi?id=68387,I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): URL,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,['I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): URL'],NA,0,I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): URL,INVESTIGATION AND EXPLORATION,, 19416,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",It's currently working for me from an iPhone.,1409703023,PHID-USER-a5pveeqqwaddgfjiv2fq,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,It's currently working for me from an iPhone.,It's currently working for me from an iPhone.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"[""It's currently working for me from an iPhone.""]",NA,0,It's currently working for me from an iPhone.,BUG REPRODUCTION,, 19417,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",I'm getting redirected to the ssl version of https://en.wikipedia.beta.wmflabs.org when I login using Safari and that is broken. Not sure why the https redirect is happening.,1409702952,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,I'm getting redirected to the ssl version of https://en.wikipedia.beta.wmflabs.org when I login using Safari and that is broken. Not sure why the https redirect is happening.,I'm getting redirected to the ssl version of URL when I login using Safari and that is broken. Not sure why the https redirect is happening.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""I'm getting redirected to the ssl version of URL when I login using Safari and that is broken."", 'Not sure why the https redirect is happening.']",NA,0,Not sure why the https redirect is happening.,INVESTIGATION AND EXPLORATION,, 19417,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",I'm getting redirected to the ssl version of https://en.wikipedia.beta.wmflabs.org when I login using Safari and that is broken. Not sure why the https redirect is happening.,1409702952,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,I'm getting redirected to the ssl version of https://en.wikipedia.beta.wmflabs.org when I login using Safari and that is broken. Not sure why the https redirect is happening.,I'm getting redirected to the ssl version of URL when I login using Safari and that is broken. Not sure why the https redirect is happening.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""I'm getting redirected to the ssl version of URL when I login using Safari and that is broken."", 'Not sure why the https redirect is happening.']",NA,0,I'm getting redirected to the ssl version of URL when I login using Safari and that is broken.,OBSERVED BUG BEHAVIOR,, 19418,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?",1409702026,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?","Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Changing summary accordingly.', 'Chris or anyone with a Macbook: can you reproduce?']",NA,0,Changing summary accordingly.,ACTION ON ISSUE ,, 19418,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?",1409702026,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?","Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Changing summary accordingly.', 'Chris or anyone with a Macbook: can you reproduce?']",NA,0,Chris or anyone with a Macbook: can you reproduce?,BUG REPRODUCTION,, 19419,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).",1409701817,PHID-USER-yu5wnmvkjecufsjgh2fa,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).","It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"[""It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).""]",NA,0,"It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).",BUG REPRODUCTION,, 19420,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,1409297457,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['The beta cluster was barely available since last friday so that might be related.', 'Do you reproduce the issue using a desktop browser?']",NA,0,The beta cluster was barely available since last friday so that might be related.,INVESTIGATION AND EXPLORATION,, 19420,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,1409297457,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['The beta cluster was barely available since last friday so that might be related.', 'Do you reproduce the issue using a desktop browser?']",NA,0,Do you reproduce the issue using a desktop browser?,BUG REPRODUCTION,, 19421,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","(In reply to Maryana Pinchuk from comment #0) > I've observed this for a couple weeks now at various times on multiple iOS > devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or > maybe just Safari; not sure. Is it 100% of the time or sporadic?",1409275841,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"(In reply to Maryana Pinchuk from comment #0) > I've observed this for a couple weeks now at various times on multiple iOS > devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or > maybe just Safari; not sure. Is it 100% of the time or sporadic?","(In reply to Maryana Pinchuk from comment #0) QUOTE QUOTE QUOTE Is it 100% of the time or sporadic?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,['(In reply to Maryana Pinchuk from comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nIs it 100% of the time or sporadic?'],NA,0,(In reply to Maryana Pinchuk from comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nIs it 100% of the time or sporadic?,INVESTIGATION AND EXPLORATION,, 19422,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",1409271797,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.', 'After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""', 'Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.', 'However, the logout button did not work.', 'I may have fat-fingered it, but it only brought me to my user page.']",NA,0,I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.,BUG REPRODUCTION,, 19422,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",1409271797,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.', 'After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""', 'Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.', 'However, the logout button did not work.', 'I may have fat-fingered it, but it only brought me to my user page.']",NA,0,"After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""",OBSERVED BUG BEHAVIOR,, 19422,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",1409271797,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.', 'After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""', 'Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.', 'However, the logout button did not work.', 'I may have fat-fingered it, but it only brought me to my user page.']",NA,0,Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.,WORKAROUND,, 19422,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",1409271797,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.', 'After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""', 'Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.', 'However, the logout button did not work.', 'I may have fat-fingered it, but it only brought me to my user page.']",NA,0,"However, the logout button did not work.",OBSERVED BUG BEHAVIOR,, 19422,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",1409271797,PHID-USER-kqibbfgfpgocyzwe32lv,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,"I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.","I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address."" Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-44,TRUE,"['I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org.', 'After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message ""Mobile domains are not served from this server IP address.""', 'Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully.', 'However, the logout button did not work.', 'I may have fat-fingered it, but it only brought me to my user page.']",NA,0,"I may have fat-fingered it, but it only brought me to my user page.",BUG REPRODUCTION,, 19423,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,1409270666,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Clarifying that this is just mobile web.', 'The mobile apps intentionally cannot log into beta labs.']",NA,0,Clarifying that this is just mobile web.,BUG REPRODUCTION,, 19423,"Safari sets forceHTTPS=deleted incorrectly, causing login failure on Beta Cluster",Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,1409270666,PHID-USER-kve2ug5yc3dp6ighnmqk,PHID-TASK-2mnvp7bdsv6ujlrtpper,task_subcomment,Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-44,TRUE,"['Clarifying that this is just mobile web.', 'The mobile apps intentionally cannot log into beta labs.']",NA,0,The mobile apps intentionally cannot log into beta labs.,INVESTIGATION AND EXPLORATION,, 19488,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=73199",1406311200,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-5kuaqwar366utx6ten4q,task_description,"Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273./n/nLooks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=73199","Warning: file_get_contents(): Peer certificate CN=CODEmeta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273./n/nLooks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,FALSE,FALSE,-49,TRUE,"[""Warning: file_get_contents(): Peer certificate CN=CODEmeta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273."", 'Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,, 19488,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=73199",1406311200,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-5kuaqwar366utx6ten4q,task_description,"Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273./n/nLooks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=73199","Warning: file_get_contents(): Peer certificate CN=CODEmeta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273./n/nLooks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424 -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",Medium,50,NA,NA,open,TRUE,c3,1,FALSE,FALSE,-49,TRUE,"[""Warning: file_get_contents(): Peer certificate CN=CODEmeta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273."", 'Looks like a side effect of I3c3d397d5779aa0affcfa8455c2197ac562c5424\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,Warning: file_get_contents(): Peer certificate CN=CODEmeta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273.,INVESTIGATION AND EXPLORATION,, 19489,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",1415553250,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-5kuaqwar366utx6ten4q,task_subcomment,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).","This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is the same error I have in bug 73199.', 'Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).', 'I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.', 'If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?', ').']",NA,0,This is the same error I have in bug 73199.,ISSUE CONTENT MANAGEMENT,, 19489,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",1415553250,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-5kuaqwar366utx6ten4q,task_subcomment,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).","This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is the same error I have in bug 73199.', 'Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).', 'I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.', 'If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?', ').']",NA,0,"Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).",INVESTIGATION AND EXPLORATION,, 19489,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",1415553250,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-5kuaqwar366utx6ten4q,task_subcomment,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).","This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is the same error I have in bug 73199.', 'Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).', 'I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.', 'If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?', ').']",NA,0,"I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.",INVESTIGATION AND EXPLORATION,, 19489,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",1415553250,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-5kuaqwar366utx6ten4q,task_subcomment,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).","This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is the same error I have in bug 73199.', 'Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).', 'I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.', 'If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?', ').']",NA,0,"If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?",SOLUTION DISCUSSION,, 19489,Warning: file_get_contents(): Peer certificate CN=`*.wikipedia.org' did not match expected CN=`meta.wikimedia.org' in .../extensions/SpamBlacklist/BaseBlacklist.php on line 273,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",1415553250,PHID-USER-2nopae2cxuamwcbndaih,PHID-TASK-5kuaqwar366utx6ten4q,task_subcomment,"This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).","This is the same error I have in bug 73199. Differences are: * it is not the same code (SpamBlacklist vs MediaWiki core), * it is not the same PHP function (file_get_contents vs fopen), * in bug 73199, there is a context specified (not here). I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute. If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-34,TRUE,"['This is the same error I have in bug 73199.', 'Differences are:\n* it is not the same code (SpamBlacklist vs MediaWiki core),\n* it is not the same PHP function (file_get_contents vs fopen),\n* in bug 73199, there is a context specified (not here).', 'I guess file_get_contents has a default context where the option CN_match is fixed to the requested host (I tried to dive into source code of PHP to track the default argument, but I abandonned), and new x509 certificates (like the one of the Wikimedia projects) don<6F><6E><EFBFBD>t really use the CN attribute but the subjectAltName attribute.', 'If this diagnosis is correct, a fix would be to add a context parameter with CA_match ""unset"" (setting it to null?', ').']",NA,0,).,NA,, 19941,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major",1385659320,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_description,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major","Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: URL -------------------------- **Version**: 1.23.0 **Severity**: major",Medium,50,1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,declined,TRUE,c3,1,FALSE,FALSE,-83,TRUE,"['Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async.', 'Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload.', 'For example with this picture:\nURL\n\n--------------------------\n**Version**: 1.23.0\n**Severity**: major']",FALSE,0,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async.",OBSERVED BUG BEHAVIOR,, 19941,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major",1385659320,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_description,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major","Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: URL -------------------------- **Version**: 1.23.0 **Severity**: major",Medium,50,1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,declined,TRUE,c3,1,FALSE,FALSE,-83,TRUE,"['Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async.', 'Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload.', 'For example with this picture:\nURL\n\n--------------------------\n**Version**: 1.23.0\n**Severity**: major']",FALSE,0,Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload.,OBSERVED BUG BEHAVIOR,, 19941,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major",1385659320,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_description,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: https://commons.wikimedia.org/wiki/File:Haubitzenbatterie_mittleren_Rheinbr%C3%BCcke_-_CH-BAR_-_3237358.tif -------------------------- **Version**: 1.23.0 **Severity**: major","Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async./n/nMediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload. For example with this picture: URL -------------------------- **Version**: 1.23.0 **Severity**: major",Medium,50,1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,declined,TRUE,c3,1,FALSE,FALSE,-83,TRUE,"['Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async.', 'Mediawiki gives systematically a HTTP timeout (503) although everything is OK with the upload.', 'For example with this picture:\nURL\n\n--------------------------\n**Version**: 1.23.0\n**Severity**: major']",FALSE,0,For example with this picture:\nURL\n\n--------------------------\n**Version**: 1.23.0\n**Severity**: major,OBSERVED BUG BEHAVIOR,, 19942,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.",1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.","This bug is too old and too lacking in details to be actionable. Possibly URL may help with this, but who knows. If error is still happening, please file a new bug.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,452,TRUE,"['This bug is too old and too lacking in details to be actionable.', 'Possibly URL may help with this, but who knows.', 'If error is still happening, please file a new bug.']",NA,0,This bug is too old and too lacking in details to be actionable.,ISSUE CONTENT MANAGEMENT,, 19942,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.",1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.","This bug is too old and too lacking in details to be actionable. Possibly URL may help with this, but who knows. If error is still happening, please file a new bug.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,452,TRUE,"['This bug is too old and too lacking in details to be actionable.', 'Possibly URL may help with this, but who knows.', 'If error is still happening, please file a new bug.']",NA,0,"Possibly URL may help with this, but who knows.",ISSUE CONTENT MANAGEMENT,, 19942,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.",1709361549,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"This bug is too old and too lacking in details to be actionable. Possibly https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007983 may help with this, but who knows. If error is still happening, please file a new bug.","This bug is too old and too lacking in details to be actionable. Possibly URL may help with this, but who knows. If error is still happening, please file a new bug.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,452,TRUE,"['This bug is too old and too lacking in details to be actionable.', 'Possibly URL may help with this, but who knows.', 'If error is still happening, please file a new bug.']",NA,0,"If error is still happening, please file a new bug.",ISSUE CONTENT MANAGEMENT,, 19943,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",1387281326,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"[""I don't know."", ""I don't have made systematic tests."", 'But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout.', 'I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.']",NA,0,"But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout.",BUG REPRODUCTION,, 19943,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",1387281326,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"[""I don't know."", ""I don't have made systematic tests."", 'But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout.', 'I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.']",NA,0,"I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",OBSERVED BUG BEHAVIOR,, 19943,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",1387281326,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"[""I don't know."", ""I don't have made systematic tests."", 'But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout.', 'I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.']",NA,0,I don't know.,SOCIAL CONVERSATION,, 19943,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",1387281326,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.","I don't know. I don't have made systematic tests. But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout. I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"[""I don't know."", ""I don't have made systematic tests."", 'But I have uploaded thousands of tiff files on Commons and my feeling is that everything is OK until ~95MB, over this limit you will maybe have a timeout.', 'I think that the post-treatment of the TIFF upload (checks, ...) is in some case longer than proxy/apache timeout thresholds and in such cases, this error occurs.']",NA,0,I don't have made systematic tests.,POTENTIAL NEW ISSUES AND REQUESTS,, 19944,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","(In reply to comment #4) > I mean <100MB. Then what range does ""big TIFF images"" mean if it's also smaller than 100MB?",1387280946,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"(In reply to comment #4) > I mean <100MB. Then what range does ""big TIFF images"" mean if it's also smaller than 100MB?","(In reply to comment #4) QUOTE Then what range does ""big TIFF images"" mean if it's also smaller than 100MB?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-81,TRUE,"['(In reply to comment #4)\nQUOTE\n\nThen what range does ""big TIFF images"" mean if it\'s also smaller than 100MB?']",NA,0,"(In reply to comment #4)\nQUOTE\n\nThen what range does ""big TIFF images"" mean if it\",INVESTIGATION AND EXPLORATION,, 19945,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async",I mean <100MB. I think the bug is easy to reproduce with the example I have given.,1387273189,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,I mean <100MB. I think the bug is easy to reproduce with the example I have given.,I mean <100MB. I think the bug is easy to reproduce with the example I have given.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"['I mean <100MB.', 'I think the bug is easy to reproduce with the example I have given.']",NA,0,I mean <100MB.,INVESTIGATION AND EXPLORATION,, 19945,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async",I mean <100MB. I think the bug is easy to reproduce with the example I have given.,1387273189,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,I mean <100MB. I think the bug is easy to reproduce with the example I have given.,I mean <100MB. I think the bug is easy to reproduce with the example I have given.,NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-81,TRUE,"['I mean <100MB.', 'I think the bug is easy to reproduce with the example I have given.']",NA,0,I think the bug is easy to reproduce with the example I have given.,BUG REPRODUCTION,, 19946,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.",1387272597,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.","Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-81,TRUE,"['Did you mean >100MB instead of <100MB in the bug summary?', 'If so, feel free to fix.']",NA,0,Did you mean >100MB instead of <100MB in the bug summary?,INVESTIGATION AND EXPLORATION,, 19946,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.",1387272597,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.","Did you mean >100MB instead of <100MB in the bug summary? If so, feel free to fix.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-81,TRUE,"['Did you mean >100MB instead of <100MB in the bug summary?', 'If so, feel free to fix.']",NA,0,"If so, feel free to fix.",CONTRIBUTION AND COMMITMENT,, 19947,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","This is done using the API action=upload, without stash, without async. The most simple way.",1385719037,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"This is done using the API action=upload, without stash, without async. The most simple way.","This is done using the API action=upload, without stash, without async. The most simple way.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-83,TRUE,"['This is done using the API action=upload, without stash, without async.', 'The most simple way.']",NA,0,"This is done using the API action=upload, without stash, without async.",INVESTIGATION AND EXPLORATION,, 19947,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","This is done using the API action=upload, without stash, without async. The most simple way.",1385719037,PHID-USER-nwa6c3hm5nmv7ixrih4p,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"This is done using the API action=upload, without stash, without async. The most simple way.","This is done using the API action=upload, without stash, without async. The most simple way.",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-83,TRUE,"['This is done using the API action=upload, without stash, without async.', 'The most simple way.']",NA,0,The most simple way.,SOCIAL CONVERSATION,, 19948,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).",1385680773,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).","For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-83,TRUE,"['For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used.', ""If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).""]",NA,0,"For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used.",ISSUE CONTENT MANAGEMENT,, 19948,"Systematic HTTP 503 timeouts by uploading big (<100MB) TIFF images via API action=upload, without stash, without async","For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).",1385680773,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-dni353kodl3tg2m3q3t3,task_subcomment,"For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).","For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used. If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-83,TRUE,"['For these types of bugs, please include method of upload (aka was chunked upload used, and in particular was the async option used.', ""If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).""]",NA,0,"If you're not sure just include which program used to upload - UploadWizard, Special:Upload, or something else).",ISSUE CONTENT MANAGEMENT,, 20119,OAuth does not set correct JWT issuer when accessing over HTTPS,"I am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",1407492180,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_description,"OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal","OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,declined,TRUE,c3,1,FALSE,FALSE,-47,TRUE,"['OAuth does not set correct JWT issuer when accessing over HTTPS.', 'I am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS).', 'Because of this verification fails.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,OAuth does not set correct JWT issuer when accessing over HTTPS.,OBSERVED BUG BEHAVIOR,, 20119,OAuth does not set correct JWT issuer when accessing over HTTPS,"I am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",1407492180,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_description,"OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal","OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,declined,TRUE,c3,1,FALSE,FALSE,-47,TRUE,"['OAuth does not set correct JWT issuer when accessing over HTTPS.', 'I am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS).', 'Because of this verification fails.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,I am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS).,OBSERVED BUG BEHAVIOR,, 20119,OAuth does not set correct JWT issuer when accessing over HTTPS,"I am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",1407492180,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_description,"OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal","OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,declined,TRUE,c3,1,FALSE,FALSE,-47,TRUE,"['OAuth does not set correct JWT issuer when accessing over HTTPS.', 'I am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS).', 'Because of this verification fails.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,Because of this verification fails.,OBSERVED BUG BEHAVIOR,, 20119,OAuth does not set correct JWT issuer when accessing over HTTPS,"I am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",1407492180,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_description,"OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (https://www.mediawiki.org), but the issuer (iss field) I am getting back from the service says http://www.mediawiki.org (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal","OAuth does not set correct JWT issuer when accessing over HTTPS./n/nI am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS). Because of this verification fails. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,declined,TRUE,c3,1,FALSE,FALSE,-47,TRUE,"['OAuth does not set correct JWT issuer when accessing over HTTPS.', 'I am accessing OAuth over HTTPS (URL but the issuer (iss field) I am getting back from the service says URL (no HTTPS).', 'Because of this verification fails.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 20120,OAuth does not set correct JWT issuer when accessing over HTTPS,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,397,TRUE,"['Bug from the era before TLS was basically required to operate a website.', 'Certainly this does not effect Wikimedia wikis anymore.']",NA,0,Bug from the era before TLS was basically required to operate a website.,ISSUE CONTENT MANAGEMENT,, 20120,OAuth does not set correct JWT issuer when accessing over HTTPS,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,1676417158,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,Bug from the era before TLS was basically required to operate a website. Certainly this does not effect Wikimedia wikis anymore.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,397,TRUE,"['Bug from the era before TLS was basically required to operate a website.', 'Certainly this does not effect Wikimedia wikis anymore.']",NA,0,Certainly this does not effect Wikimedia wikis anymore.,ISSUE CONTENT MANAGEMENT,, 20121,OAuth does not set correct JWT issuer when accessing over HTTPS,Does not affect Wikimedia sites anymore since it is not possible for the access method and the canonical server URL to have different protocols.,1488864256,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,Does not affect Wikimedia sites anymore since it is not possible for the access method and the canonical server URL to have different protocols.,Does not affect Wikimedia sites anymore since it is not possible for the access method and the canonical server URL to have different protocols.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,87,TRUE,['Does not affect Wikimedia sites anymore since it is not possible for the access method and the canonical server URL to have different protocols.'],NA,0,Does not affect Wikimedia sites anymore since it is not possible for the access method and the canonical server URL to have different protocols.,ISSUE CONTENT MANAGEMENT,, 20122,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Chris Steipp from comment #1) > If we use $wgServer, you have the same > problem that you can't match the protocol. wfExpandUrl( $wgServer, PROTO_CURRENT ) maybe?",1407529004,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Chris Steipp from comment #1) > If we use $wgServer, you have the same > problem that you can't match the protocol. wfExpandUrl( $wgServer, PROTO_CURRENT ) maybe?","(In reply to Chris Steipp from comment #1) QUOTE QUOTE wfExpandUrl( $wgServer, PROTO_CURRENT ) maybe?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Chris Steipp from comment #1)\nQUOTE\nQUOTE\n\nwfExpandUrl( $wgServer, PROTO_CURRENT ) maybe?']",NA,0,"(In reply to Chris Steipp from comment #1)\nQUOTE\nQUOTE\n\nwfExpandUrl( $wgServer, PROTO_CURRENT ) maybe?",SOCIAL CONVERSATION,, 20123,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",1407518980,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)","Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?', 'OAuth should simply be declined without HTTPS?', 'There is really no need for HTTP for APIs.', '(CPU ought not be an excuse.)', '(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)']",NA,0,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?",SOLUTION DISCUSSION,, 20123,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",1407518980,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)","Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?', 'OAuth should simply be declined without HTTPS?', 'There is really no need for HTTP for APIs.', '(CPU ought not be an excuse.)', '(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)']",NA,0,OAuth should simply be declined without HTTPS?,SOLUTION DISCUSSION,, 20123,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",1407518980,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)","Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?', 'OAuth should simply be declined without HTTPS?', 'There is really no need for HTTP for APIs.', '(CPU ought not be an excuse.)', '(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)']",NA,0,There is really no need for HTTP for APIs.,SOLUTION DISCUSSION,, 20123,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",1407518980,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)","Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?', 'OAuth should simply be declined without HTTPS?', 'There is really no need for HTTP for APIs.', '(CPU ought not be an excuse.)', '(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)']",NA,0,(CPU ought not be an excuse.),SOLUTION DISCUSSION,, 20123,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",1407518980,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)","Hm, maybe we could just require anyone using OAuth to use HTTPS at all times? OAuth should simply be declined without HTTPS? There is really no need for HTTP for APIs. (CPU ought not be an excuse.) (For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, maybe we could just require anyone using OAuth to use HTTPS at all times?', 'OAuth should simply be declined without HTTPS?', 'There is really no need for HTTP for APIs.', '(CPU ought not be an excuse.)', '(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.)']",NA,0,(For other installations other could decide on configuration and deal with correctly setting wgCanonicalServer.),WORKAROUND,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,"(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\",INVESTIGATION AND EXPLORATION,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,", ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user",SOLUTION DISCUSSION,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,"t great design I admin."", ",SOCIAL CONVERSATION,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,", ""QUOTE\nQUOTE\nQUOTE\n\nI think I",NA,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,"t include protocol, so back to the same problem."", ",SOCIAL CONVERSATION,, 20124,OAuth does not set correct JWT issuer when accessing over HTTPS,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)",1407518267,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"(In reply to Mitar from comment #2) > Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong > $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it > redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical > URL for the site. www.mediawiki.org has $wgCanonicalServer set to ""http://www.mediawiki.org"". If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. > Server name could not be influenced by an attacker (if yes, you have an > error in your server configuration)? But http host yes. But server name does > not contain the protocol anyway, no? I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. > You could use $_SERVER[""HTTPS""]: > https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using- > https-without-serverhttps > > But then you will have to make sure that your forward proxy daemon properly > sets this (if you run MediaWiki behind it, what you do at mediawiki.org it > seems). $request->getProtocol(). You've been away too long :)","(In reply to Mitar from comment #2) QUOTE QUOTE QUOTE QUOTE www.mediawiki.org has $wgCanonicalServer set to ""URL If you're logged in, you probably have the force HTTPS cookie which is causing the redirect. But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else. So the in the preferred case, there will be a missmatch, which isn't great design I admin. We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too. QUOTE QUOTE QUOTE I think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE $request->getProtocol(). You've been away too long :)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['(In reply to Mitar from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nwww.mediawiki.org has $wgCanonicalServer set to ""URL If you\'re logged in, you probably have the force HTTPS cookie which is causing the redirect.', ""But yeah, I prefer you *DO* use https when calling /identify, just to preserve your user's privacy, if nothing else."", ""So the in the preferred case, there will be a missmatch, which isn't great design I admin."", 'We could just set https:// always, to encourage Consumer to use it too.. but that seems a little evil too.', ""QUOTE\nQUOTE\nQUOTE\n\nI think I've seen the host header used when apache used * as the vhost... but yeah, as you point out that doesn't include protocol, so back to the same problem."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\n$request->getProtocol().', ""You've been away too long :)""]",NA,0,", ""You",NA,, 20125,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",1407517342,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)","Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, it seems it does not redirect to HTTPS on all my browsers.', 'Maybe this is HTTPS Anywhere.', ':-)']",NA,0,"Hm, it seems it does not redirect to HTTPS on all my browsers.",BUG REPRODUCTION,, 20125,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",1407517342,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)","Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, it seems it does not redirect to HTTPS on all my browsers.', 'Maybe this is HTTPS Anywhere.', ':-)']",NA,0,Maybe this is HTTPS Anywhere.,INVESTIGATION AND EXPLORATION,, 20125,OAuth does not set correct JWT issuer when accessing over HTTPS,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",1407517342,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)","Hm, it seems it does not redirect to HTTPS on all my browsers. Maybe this is HTTPS Anywhere. :-)",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Hm, it seems it does not redirect to HTTPS on all my browsers.', 'Maybe this is HTTPS Anywhere.', ':-)']",NA,0,:-),SOCIAL CONVERSATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.,INVESTIGATION AND EXPLORATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,Because if you open URL it redirects to HTTPS.,OBSERVED BUG BEHAVIOR,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,So it seems URL is the canonical URL for the site.,INVESTIGATION AND EXPLORATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,"Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?",INVESTIGATION AND EXPLORATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,But http host yes.,INVESTIGATION AND EXPLORATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,"But server name does not contain the protocol anyway, no?",INVESTIGATION AND EXPLORATION,, 20126,OAuth does not set correct JWT issuer when accessing over HTTPS,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",1407517241,PHID-USER-m2xiute3l4kwb26dyrp7,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"Then maybe MediaWiki (https://www.mediawiki.org/wiki/MediaWiki) has a wrong $wgCanonicalServer setting. Because if you open http://www.mediawiki.org it redirects to HTTPS. So it seems https://www.mediawiki.org is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: https://stackoverflow.com/questions/1175096/how-to-find-out-if-you-are-using-https-without-serverhttps But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).","Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting. Because if you open URL it redirects to HTTPS. So it seems URL is the canonical URL for the site. Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)? But http host yes. But server name does not contain the protocol anyway, no? You could use $_SERVER[""HTTPS""]: URL But then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-47,TRUE,"['Then maybe MediaWiki (URL has a wrong $wgCanonicalServer setting.', 'Because if you open URL it redirects to HTTPS.', 'So it seems URL is the canonical URL for the site.', 'Server name could not be influenced by an attacker (if yes, you have an error in your server configuration)?', 'But http host yes.', 'But server name does not contain the protocol anyway, no?', 'You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).']",NA,0,"You could use $_SERVER[""HTTPS""]: URL\n\nBut then you will have to make sure that your forward proxy daemon properly sets this (if you run MediaWiki behind it, what you do at mediawiki.org it seems).",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,Just not sure what the best answer is.,SOCIAL CONVERSATION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url.",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker.",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"If we use $wgServer, you have the same problem that you can't match the protocol.",SOLUTION DISCUSSION,, 20127,OAuth does not set correct JWT issuer when accessing over HTTPS,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",1407516765,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-65frrvpzvit7upklaj5l,task_subcomment,"I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- https://github.com/Stype/mwoauth-php). Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.","I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name. To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url. We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker. If we use $wgServer, you have the same problem that you can't match the protocol. Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol. That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it. Just not sure what the best answer is.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-47,TRUE,"['I set iss to $wgCanonicalServer, since that is the most stable and, canonical, representation of the server name.', ""To get around the verification failure, you can either keep track of what the canonical server name is supposed to be (that's what I do in the php library I maintain- URL Or in Phabricator, we pull off the protocol and just compare the host portion of the url."", ""We can't use $_SERVER['SERVER_NAME'] / $_SERVER['HTTP_HOST'], because those can be influenced by an attacker."", ""If we use $wgServer, you have the same problem that you can't match the protocol."", 'Probably the only realistic enhancement would be to use wgCanonicalServer, but update the protocol.', ""That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it."", 'Just not sure what the best answer is.']",NA,0,"That seems more confusing to me, but this issue has been reported (personally) to me enough times, that I'm open to changing it.",CONTRIBUTION AND COMMITMENT,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,memcached / httpGet failing sometimes.,OBSERVED BUG BEHAVIOR,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.,OBSERVED BUG BEHAVIOR,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.",INVESTIGATION AND EXPLORATION,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Until the issue surfaces again, we will not be able to analyze this further.",FUTURE PLANS,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.",INVESTIGATION AND EXPLORATION,, 20179,memcached / httpGet failing sometimes,"memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",1401300060,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_description,"memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal","memcached / httpGet failing sometimes./n/nmemcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed. This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented. Until the issue surfaces again, we will not be able to analyze this further. flourine $ grep memcache /a/mw-log/zero.log Not all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged. -------------------------- **Version**: unspecified **Severity**: normal",Low,25,1546559056,PHID-USER-6vzzsmi22zem6yttr6vp,declined,TRUE,c3,1,TRUE,FALSE,-58,TRUE,"['memcached / httpGet failing sometimes.', 'memcached and Wikipedia app server - to - zero.wikimedia.org app server HTTP GET failures have been observed.', 'This means that the Wikipedia Zero banners may not show and pages may not be rewritten, or they may be inaccurately presented.', 'Until the issue surfaces again, we will not be able to analyze this further.', 'flourine $ grep memcache /a/mw-log/zero.log\n\nNot all items with !memcache in the log are necessarily hard failures due to the state machine aspect of memcached object clear and update, but use that command to identify entries and see the ZeroRatedMobileAccess extension for the specific places things are logged.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, 20180,memcached / httpGet failing sometimes,"Yep, it causes banners to not show, or it causes stale versions of pages to be served incorrectly, or both.",1401304858,PHID-USER-srhlj2447vmpmrfhqnfa,PHID-TASK-7hkmizsbasap4yirathu,task_subcomment,"Yep, it causes banners to not show, or it causes stale versions of pages to be served incorrectly, or both.","Yep, it causes banners to not show, or it causes stale versions of pages to be served incorrectly, or both.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-58,TRUE,"['Yep, it causes banners to not show, or it causes stale versions of pages to be served incorrectly, or both.']",NA,0,"Yep, it causes banners to not show, or it causes stale versions of pages to be served incorrectly, or both.",OBSERVED BUG BEHAVIOR,, 20181,memcached / httpGet failing sometimes,"Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)",1401303963,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-7hkmizsbasap4yirathu,task_subcomment,"Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)","Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-58,TRUE,"['Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right?', ""I trust you'll ping this bug when that happens ;)\n\n(Setting to Low until that happens again.)""]",NA,0,"Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right?",FUTURE PLANS,, 20181,memcached / httpGet failing sometimes,"Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)",1401303963,PHID-USER-z3l4i7dl52qicxtephy5,PHID-TASK-7hkmizsbasap4yirathu,task_subcomment,"Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)","Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right? I trust you'll ping this bug when that happens ;) (Setting to Low until that happens again.)",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-58,TRUE,"['Just to confirm, the issue that we need to wait to surface again is Zero banners not showing up correctly, right?', ""I trust you'll ping this bug when that happens ;)\n\n(Setting to Low until that happens again.)""]",NA,0,I trust you'll ping this bug when that happens ;)\n\n(Setting to Low until that happens again.),ACTION ON ISSUE,, 20546,*.wmflabs.org https certificate expired (tools.wmflabs.org),"tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",1442278926,PHID-USER-mcfo27pkfdhzd7gk66fx,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_description,"*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ","*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",Unbreak Now!,100,1442333214,PHID-USER-h75guknmwivm6x37iute,resolved,TRUE,c3,3,FALSE,FALSE,10,TRUE,"['*.wmflabs.org https certificate expired (tools.wmflabs.org).', 'tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM.', 'This is the star.wmflabs.org certificate which is also used for https in the labs proxy.']",TRUE,0,*.wmflabs.org https certificate expired (tools.wmflabs.org).,OBSERVED BUG BEHAVIOR,, 20546,*.wmflabs.org https certificate expired (tools.wmflabs.org),"tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",1442278926,PHID-USER-mcfo27pkfdhzd7gk66fx,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_description,"*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ","*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",Unbreak Now!,100,1442333214,PHID-USER-h75guknmwivm6x37iute,resolved,TRUE,c3,3,FALSE,FALSE,10,TRUE,"['*.wmflabs.org https certificate expired (tools.wmflabs.org).', 'tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM.', 'This is the star.wmflabs.org certificate which is also used for https in the labs proxy.']",TRUE,0,tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM.,OBSERVED BUG BEHAVIOR,, 20546,*.wmflabs.org https certificate expired (tools.wmflabs.org),"tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",1442278926,PHID-USER-mcfo27pkfdhzd7gk66fx,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_description,"*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ","*.wmflabs.org https certificate expired (tools.wmflabs.org)./n/ntools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM. This is the star.wmflabs.org certificate which is also used for https in the labs proxy. ",Unbreak Now!,100,1442333214,PHID-USER-h75guknmwivm6x37iute,resolved,TRUE,c3,3,FALSE,FALSE,10,TRUE,"['*.wmflabs.org https certificate expired (tools.wmflabs.org).', 'tools.wmflabs.org https certificate expired certificate expired on 15-09-14 08:43 PM.', 'This is the star.wmflabs.org certificate which is also used for https in the labs proxy.']",TRUE,0,This is the star.wmflabs.org certificate which is also used for https in the labs proxy.,MOTIVATION,, 20547,*.wmflabs.org https certificate expired (tools.wmflabs.org),Left to be done is to add a monitoring probe for the certificate expiry {T112645},1442394664,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,Left to be done is to add a monitoring probe for the certificate expiry {T112645},Left to be done is to add a monitoring probe for the certificate expiry {T112645},NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,['Left to be done is to add a monitoring probe for the certificate expiry {T112645}'],NA,0,Left to be done is to add a monitoring probe for the certificate expiry {T112645},ISSUE CONTENT MANAGEMENT,, 20548,*.wmflabs.org https certificate expired (tools.wmflabs.org),">>! In T112608#1641865, @coren wrote: > The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). > > As far as I can tell, that covers everything. Thanks for the quick solution - things look fine to me now when I open https://tools.wmflabs.org/ or pull up a Wikivoyage map such as https://en.wikivoyage.org/wiki/Culver_City#Get_around.",1442348937,PHID-USER-2q4czpdve2m2bm74ksx5,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,">>! In T112608#1641865, @coren wrote: > The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). > > As far as I can tell, that covers everything. Thanks for the quick solution - things look fine to me now when I open https://tools.wmflabs.org/ or pull up a Wikivoyage map such as https://en.wikivoyage.org/wiki/Culver_City#Get_around.","QUOTE QUOTE QUOTE QUOTE Thanks for the quick solution - things look fine to me now when I open URL or pull up a Wikivoyage map such as URL",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,['QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThanks for the quick solution - things look fine to me now when I open URL or pull up a Wikivoyage map such as URL'],NA,0,QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThanks for the quick solution - things look fine to me now when I open URL or pull up a Wikivoyage map such as URL,BUG REPRODUCTION,, 20549,*.wmflabs.org https certificate expired (tools.wmflabs.org),"The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ",1442333214,PHID-USER-h75guknmwivm6x37iute,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ","The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers)."", 'As far as I can tell, that covers everything.']",NA,0,"As far as I can tell, that covers everything.",TASK PROGRESS,, 20549,*.wmflabs.org https certificate expired (tools.wmflabs.org),"The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ",1442333214,PHID-USER-h75guknmwivm6x37iute,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ","The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers). As far as I can tell, that covers everything. ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers)."", 'As far as I can tell, that covers everything.']",NA,0,"The new certificates have been issued, and I've pushed them to the servers (specifically, the labs-wide dynamicproxy and the tools-specific proxies and static web servers).",TASK PROGRESS,, 20550,*.wmflabs.org https certificate expired (tools.wmflabs.org),We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,1442296227,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"['We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens.', 'Might be up to midday west coast time however :(']",NA,0,We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens.,TASK PROGRESS,, 20550,*.wmflabs.org https certificate expired (tools.wmflabs.org),We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,1442296227,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens. Might be up to midday west coast time however :(,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"['We are waiting on the CA to re-issue the certificate and will be back online as soon as that happens.', 'Might be up to midday west coast time however :(']",NA,0,Might be up to midday west coast time however :(,FUTURE PLANS,, 20551,*.wmflabs.org https certificate expired (tools.wmflabs.org),">>! In T112608#1640292, @Negative24 wrote: > Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made) There is a maps.wikimedia.org service in progress that I believe is supposed to be a more ""official"" maps service - see Yurik's comments at the end of the https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Dynamic_maps thread - but my understanding is that it is still a work-in-progress and that issues still need to be resolved.",1442295731,PHID-USER-2q4czpdve2m2bm74ksx5,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,">>! In T112608#1640292, @Negative24 wrote: > Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made) There is a maps.wikimedia.org service in progress that I believe is supposed to be a more ""official"" maps service - see Yurik's comments at the end of the https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Dynamic_maps thread - but my understanding is that it is still a work-in-progress and that issues still need to be resolved.","QUOTE QUOTE There is a maps.wikimedia.org service in progress that I believe is supposed to be a more ""official"" maps service - see Yurik's comments at the end of the URL thread - but my understanding is that it is still a work-in-progress and that issues still need to be resolved.",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['QUOTE\nQUOTE\n\nThere is a maps.wikimedia.org service in progress that I believe is supposed to be a more ""official"" maps service - see Yurik\'s comments at the end of the URL thread - but my understanding is that it is still a work-in-progress and that issues still need to be resolved.']",NA,0,"QUOTE\nQUOTE\n\nThere is a maps.wikimedia.org service in progress that I believe is supposed to be a more ""official"" maps service - see Yurik\",EXPECTED BEHAVIOR,, 20552,*.wmflabs.org https certificate expired (tools.wmflabs.org),"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",1442285407,PHID-USER-zcsdm7lwcehnusyhh6xp,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)","Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences?', ""From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine."", '(topic for another task; cc me if one is made)']",NA,0,Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences?,SOLUTION DISCUSSION,, 20552,*.wmflabs.org https certificate expired (tools.wmflabs.org),"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",1442285407,PHID-USER-zcsdm7lwcehnusyhh6xp,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)","Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences?', ""From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine."", '(topic for another task; cc me if one is made)']",NA,0,(topic for another task; cc me if one is made),ISSUE CONTENT MANAGEMENT,, 20552,*.wmflabs.org https certificate expired (tools.wmflabs.org),"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",1442285407,PHID-USER-zcsdm7lwcehnusyhh6xp,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)","Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences?', ""From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine."", '(topic for another task; cc me if one is made)']",NA,0,"From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine.",ISSUE CONTENT MANAGEMENT,, 20553,*.wmflabs.org https certificate expired (tools.wmflabs.org),"Thanks for working on this :-) Just for info, this breaks most Wikivoyage articles (they embed a dynamic map frame generated by tools.wmflabs.org): {F2604942}",1442284975,PHID-USER-qmcrs2npimuywblubznv,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"Thanks for working on this :-) Just for info, this breaks most Wikivoyage articles (they embed a dynamic map frame generated by tools.wmflabs.org): {F2604942}","Thanks for working on this :-) Just for info, this breaks most Wikivoyage articles (they embed a dynamic map frame generated by tools.wmflabs.org): {F2604942}",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['Thanks for working on this :-)\n\nJust for info, this breaks most Wikivoyage articles (they embed a dynamic map frame generated by tools.wmflabs.org):\n{F2604942}']",NA,0,"Thanks for working on this :-)\n\nJust for info, this breaks most Wikivoyage articles (they embed a dynamic map frame generated by tools.wmflabs.org):\n{F2604942}",OBSERVED BUG BEHAVIOR,, 20554,*.wmflabs.org https certificate expired (tools.wmflabs.org),T112542 refers to a 'tracking calendar'. And this is sort of part of that.,1442280442,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,T112542 refers to a 'tracking calendar'. And this is sort of part of that.,T112542 refers to a 'tracking calendar'. And this is sort of part of that.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""T112542 refers to a 'tracking calendar'."", 'And this is sort of part of that.']",NA,0,And this is sort of part of that.,SOCIAL CONVERSATION,, 20554,*.wmflabs.org https certificate expired (tools.wmflabs.org),T112542 refers to a 'tracking calendar'. And this is sort of part of that.,1442280442,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,T112542 refers to a 'tracking calendar'. And this is sort of part of that.,T112542 refers to a 'tracking calendar'. And this is sort of part of that.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""T112542 refers to a 'tracking calendar'."", 'And this is sort of part of that.']",NA,0,T112542 refers to a 'tracking calendar'.,ISSUE CONTENT MANAGEMENT,, 20555,*.wmflabs.org https certificate expired (tools.wmflabs.org),"I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.",1442280007,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.","I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""I think there's a calendar somewhere with expiry dates, and this cert was just missed."", ""I'll verify and make sure there's one such calendar.""]",NA,0,"I think there's a calendar somewhere with expiry dates, and this cert was just missed.",SOLUTION DISCUSSION,, 20555,*.wmflabs.org https certificate expired (tools.wmflabs.org),"I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.",1442280007,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.","I think there's a calendar somewhere with expiry dates, and this cert was just missed. I'll verify and make sure there's one such calendar.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"[""I think there's a calendar somewhere with expiry dates, and this cert was just missed."", ""I'll verify and make sure there's one such calendar.""]",NA,0,I'll verify and make sure there's one such calendar.,CONTRIBUTION AND COMMITMENT,, 20556,*.wmflabs.org https certificate expired (tools.wmflabs.org),"Now, how will we remember to do this in the future?",1442279968,PHID-USER-zcsdm7lwcehnusyhh6xp,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,"Now, how will we remember to do this in the future?","Now, how will we remember to do this in the future?",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,"['Now, how will we remember to do this in the future?']",NA,0,"Now, how will we remember to do this in the future?",FUTURE PLANS,, 20557,*.wmflabs.org https certificate expired (tools.wmflabs.org),Looks like it might take us a day or so to renew them. Ugh.,1442279540,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,Looks like it might take us a day or so to renew them. Ugh.,Looks like it might take us a day or so to renew them. Ugh.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"['Looks like it might take us a day or so to renew them.', 'Ugh.']",NA,0,Looks like it might take us a day or so to renew them.,SOLUTION DISCUSSION,, 20557,*.wmflabs.org https certificate expired (tools.wmflabs.org),Looks like it might take us a day or so to renew them. Ugh.,1442279540,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-k5hfdjpbqfhjvcjq5qxr,task_subcomment,Looks like it might take us a day or so to renew them. Ugh.,Looks like it might take us a day or so to renew them. Ugh.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,"['Looks like it might take us a day or so to renew them.', 'Ugh.']",NA,0,Ugh.,SOCIAL CONVERSATION,, 20885,Thumbnail render throttling should not result in HTTP 500,"`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",1440449935,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-tsna5tqdourvyes6rfrj,task_description,"Thumbnail render throttling should not result in HTTP 500./n/n`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)","Thumbnail render throttling should not result in HTTP 500./n/nCODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when CODE returns false * when the CODE memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",Needs Triage,90,1440627893,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['Thumbnail render throttling should not result in HTTP 500.', 'CODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling.', 'That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).', 'There are multiple places where this needs to be fixed:\n* when CODE returns false\n* when the CODE memcached key hits the limit\n* when PoolCounter refuses to take the job (can that happen?)']",TRUE,0,Thumbnail render throttling should not result in HTTP 500.,EXPECTED BEHAVIOR,, 20885,Thumbnail render throttling should not result in HTTP 500,"`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",1440449935,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-tsna5tqdourvyes6rfrj,task_description,"Thumbnail render throttling should not result in HTTP 500./n/n`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)","Thumbnail render throttling should not result in HTTP 500./n/nCODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when CODE returns false * when the CODE memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",Needs Triage,90,1440627893,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['Thumbnail render throttling should not result in HTTP 500.', 'CODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling.', 'That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).', 'There are multiple places where this needs to be fixed:\n* when CODE returns false\n* when the CODE memcached key hits the limit\n* when PoolCounter refuses to take the job (can that happen?)']",TRUE,0,"CODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling.",OBSERVED BUG BEHAVIOR,, 20885,Thumbnail render throttling should not result in HTTP 500,"`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",1440449935,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-tsna5tqdourvyes6rfrj,task_description,"Thumbnail render throttling should not result in HTTP 500./n/n`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)","Thumbnail render throttling should not result in HTTP 500./n/nCODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when CODE returns false * when the CODE memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",Needs Triage,90,1440627893,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['Thumbnail render throttling should not result in HTTP 500.', 'CODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling.', 'That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).', 'There are multiple places where this needs to be fixed:\n* when CODE returns false\n* when the CODE memcached key hits the limit\n* when PoolCounter refuses to take the job (can that happen?)']",TRUE,0,That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).,EXPECTED BEHAVIOR,, 20885,Thumbnail render throttling should not result in HTTP 500,"`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",1440449935,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-tsna5tqdourvyes6rfrj,task_description,"Thumbnail render throttling should not result in HTTP 500./n/n`thumb.php` throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when `User::pingLimiter` returns false * when the `attempt-failures` memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)","Thumbnail render throttling should not result in HTTP 500./n/nCODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling. That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests). There are multiple places where this needs to be fixed: * when CODE returns false * when the CODE memcached key hits the limit * when PoolCounter refuses to take the job (can that happen?)",Needs Triage,90,1440627893,PHID-USER-a6p24cvyblhfzc7we7nc,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['Thumbnail render throttling should not result in HTTP 500.', 'CODE throttles thumbnail rendering in various ways, and it returns a HTTP 500 if a request was refused due to throttling.', 'That is wrong and causes false alarms; a 4xx status code should be used (probably HTTP 429 Too Many Requests).', 'There are multiple places where this needs to be fixed:\n* when CODE returns false\n* when the CODE memcached key hits the limit\n* when PoolCounter refuses to take the job (can that happen?)']",TRUE,0,There are multiple places where this needs to be fixed:\n* when CODE returns false\n* when the CODE memcached key hits the limit\n* when PoolCounter refuses to take the job (can that happen?),INVESTIGATION AND EXPLORATION,, 20886,Thumbnail render throttling should not result in HTTP 500,"Change 234152 merged by jenkins-bot: Return HTTP 429 when thumbnailing is throttled due to too many errors [[https://gerrit.wikimedia.org/r/234152]]",1440627355,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-tsna5tqdourvyes6rfrj,task_subcomment,"Change 234152 merged by jenkins-bot: Return HTTP 429 when thumbnailing is throttled due to too many errors [[https://gerrit.wikimedia.org/r/234152]]","Change 234152 merged by jenkins-bot: Return HTTP 429 when thumbnailing is throttled due to too many errors [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,['Change 234152 merged by jenkins-bot:\nReturn HTTP 429 when thumbnailing is throttled due to too many errors\n\n[[GERRIT_URL]]'],NA,0,Change 234152 merged by jenkins-bot:\nReturn HTTP 429 when thumbnailing is throttled due to too many errors\n\n[[GERRIT_URL]],TASK PROGRESS,, 20887,Thumbnail render throttling should not result in HTTP 500,"Change 234152 had a related patch set uploaded (by Gerg<72><67> Tisza): Return HTTP 429 when thumbnailing is throttled due to too many errors [[https://gerrit.wikimedia.org/r/234152]] ",1440624870,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-tsna5tqdourvyes6rfrj,task_subcomment,"Change 234152 had a related patch set uploaded (by Gerg<72><67> Tisza): Return HTTP 429 when thumbnailing is throttled due to too many errors [[https://gerrit.wikimedia.org/r/234152]] ","Change 234152 had a related patch set uploaded (by Gerg<72><67> Tisza): Return HTTP 429 when thumbnailing is throttled due to too many errors [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,['Change 234152 had a related patch set uploaded (by Gerg<72><67> Tisza):\nReturn HTTP 429 when thumbnailing is throttled due to too many errors\n\n[[GERRIT_URL]]'],NA,0,Change 234152 had a related patch set uploaded (by Gerg<72><67> Tisza):\nReturn HTTP 429 when thumbnailing is throttled due to too many errors\n\n[[GERRIT_URL]],TASK PROGRESS,, 20888,Thumbnail render throttling should not result in HTTP 500,"Change 234039 merged by jenkins-bot: Reduced some instances of HTTP 500 in thumb.php [[https://gerrit.wikimedia.org/r/234039]]",1440619651,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-tsna5tqdourvyes6rfrj,task_subcomment,"Change 234039 merged by jenkins-bot: Reduced some instances of HTTP 500 in thumb.php [[https://gerrit.wikimedia.org/r/234039]]","Change 234039 merged by jenkins-bot: Reduced some instances of HTTP 500 in thumb.php [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,['Change 234039 merged by jenkins-bot:\nReduced some instances of HTTP 500 in thumb.php\n\n[[GERRIT_URL]]'],NA,0,Change 234039 merged by jenkins-bot:\nReduced some instances of HTTP 500 in thumb.php\n\n[[GERRIT_URL]],TASK PROGRESS,, 20889,Thumbnail render throttling should not result in HTTP 500,"Change 234039 had a related patch set uploaded (by Aaron Schulz): Reduced some instances of HTTP 500 in thumb.php [[https://gerrit.wikimedia.org/r/234039]] ",1440615166,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-tsna5tqdourvyes6rfrj,task_subcomment,"Change 234039 had a related patch set uploaded (by Aaron Schulz): Reduced some instances of HTTP 500 in thumb.php [[https://gerrit.wikimedia.org/r/234039]] ","Change 234039 had a related patch set uploaded (by Aaron Schulz): Reduced some instances of HTTP 500 in thumb.php [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,['Change 234039 had a related patch set uploaded (by Aaron Schulz):\nReduced some instances of HTTP 500 in thumb.php\n\n[[GERRIT_URL]]'],NA,0,Change 234039 had a related patch set uploaded (by Aaron Schulz):\nReduced some instances of HTTP 500 in thumb.php\n\n[[GERRIT_URL]],TASK PROGRESS,, 20988,Login-needed text isn't displayed for all newsletter-pages,"The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=requiredlogintext * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterManage&returntoquery=&warning=requiredlogintext Although for Special:Newsletters a (different) notice is displayed: * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletters&returntoquery=&warning=exception-nologin-text Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.",1435487640,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-uo5x4miw3tt6q2aggbse,task_description,"Login-needed text isn't displayed for all newsletter-pages./n/nThe referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=requiredlogintext * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterManage&returntoquery=&warning=requiredlogintext Although for Special:Newsletters a (different) notice is displayed: * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletters&returntoquery=&warning=exception-nologin-text Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.","Login-needed text isn't displayed for all newsletter-pages./n/nThe referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * URL * URL Although for Special:Newsletters a (different) notice is displayed: * URL Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.",Needs Triage,90,1435493401,PHID-USER-jcypqodpdpbcicgwgh7j,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"[""Login-needed text isn't displayed for all newsletter-pages."", ""The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage\n* URL\n* URL\nAlthough for Special:Newsletters a (different) notice is displayed:\n* URL\n\nProbably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.""]",TRUE,0,Login-needed text isn't displayed for all newsletter-pages.,OBSERVED BUG BEHAVIOR,, 20988,Login-needed text isn't displayed for all newsletter-pages,"The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=requiredlogintext * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterManage&returntoquery=&warning=requiredlogintext Although for Special:Newsletters a (different) notice is displayed: * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletters&returntoquery=&warning=exception-nologin-text Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.",1435487640,PHID-USER-jcypqodpdpbcicgwgh7j,PHID-TASK-uo5x4miw3tt6q2aggbse,task_description,"Login-needed text isn't displayed for all newsletter-pages./n/nThe referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=requiredlogintext * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterManage&returntoquery=&warning=requiredlogintext Although for Special:Newsletters a (different) notice is displayed: * http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletters&returntoquery=&warning=exception-nologin-text Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.","Login-needed text isn't displayed for all newsletter-pages./n/nThe referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage * URL * URL Although for Special:Newsletters a (different) notice is displayed: * URL Probably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.",Needs Triage,90,1435493401,PHID-USER-jcypqodpdpbcicgwgh7j,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"[""Login-needed text isn't displayed for all newsletter-pages."", ""The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage\n* URL\n* URL\nAlthough for Special:Newsletters a (different) notice is displayed:\n* URL\n\nProbably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.""]",TRUE,0,The referenced warning that login is needed doesn't show up for me for Special:NewsletterCreate and Special:NewsletterManage\n* URL\n* URL\nAlthough for Special:Newsletters a (different) notice is displayed:\n* URL\n\nProbably also shouldn't be 2 different messages where requiredlogintext (defined by newsletter extension) basically duplicates the other.,OBSERVED BUG BEHAVIOR,, 20989,Login-needed text isn't displayed for all newsletter-pages,^^ That made every special page on no-login uniform. @Se4598 close it if http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=exception-nologin-text looks good to you,1435492935,PHID-USER-b3xlpjqyzhcppjoumu63,PHID-TASK-uo5x4miw3tt6q2aggbse,task_subcomment,^^ That made every special page on no-login uniform. @Se4598 close it if http://newsletter-test.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Special%3ANewsletterCreate&returntoquery=&warning=exception-nologin-text looks good to you,^^ That made every special page on no-login uniform.SCREEN_NAME close it if URL looks good to you,NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-1,TRUE,['^^ That made every special page on no-login uniform.SCREEN_NAME close it if URL looks good to you'],NA,0,^^ That made every special page on no-login uniform.SCREEN_NAME close it if URL looks good to you,TASK PROGRESS,, 20990,Login-needed text isn't displayed for all newsletter-pages,"Change 221441 merged by jenkins-bot: Remove unnecessary parameter passed to requireLogin() [[https://gerrit.wikimedia.org/r/221441]]",1435492759,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-uo5x4miw3tt6q2aggbse,task_subcomment,"Change 221441 merged by jenkins-bot: Remove unnecessary parameter passed to requireLogin() [[https://gerrit.wikimedia.org/r/221441]]","Change 221441 merged by jenkins-bot: Remove unnecessary parameter passed to requireLogin() [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-1,TRUE,['Change 221441 merged by jenkins-bot:\nRemove unnecessary parameter passed to requireLogin()\n\n[[GERRIT_URL]]'],NA,0,Change 221441 merged by jenkins-bot:\nRemove unnecessary parameter passed to requireLogin()\n\n[[GERRIT_URL]],TASK PROGRESS,, 20991,Login-needed text isn't displayed for all newsletter-pages,"Change 221441 had a related patch set uploaded (by Tinaj1234): Remove unnecessary parameter passed to requireLogin() [[https://gerrit.wikimedia.org/r/221441]] ",1435491549,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-uo5x4miw3tt6q2aggbse,task_subcomment,"Change 221441 had a related patch set uploaded (by Tinaj1234): Remove unnecessary parameter passed to requireLogin() [[https://gerrit.wikimedia.org/r/221441]] ","Change 221441 had a related patch set uploaded (by Tinaj1234): Remove unnecessary parameter passed to requireLogin() [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-1,TRUE,['Change 221441 had a related patch set uploaded (by Tinaj1234):\nRemove unnecessary parameter passed to requireLogin()\n\n[[GERRIT_URL]]'],NA,0,Change 221441 had a related patch set uploaded (by Tinaj1234):\nRemove unnecessary parameter passed to requireLogin()\n\n[[GERRIT_URL]],TASK PROGRESS,, 20992,Login-needed text isn't displayed for all newsletter-pages,"That's strange. For the first two SpecialPage code, we have ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletterCreate.php#L14 ) ``` $this->requireLogin( 'requiredlogintext' ); ``` which never shows up in labs, and for the Special:Newsletter which showed up a message, the message-param was not given ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletters.php#L13 ) ``` $this->requireLogin(); ```",1435487917,PHID-USER-b3xlpjqyzhcppjoumu63,PHID-TASK-uo5x4miw3tt6q2aggbse,task_subcomment,"That's strange. For the first two SpecialPage code, we have ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletterCreate.php#L14 ) ``` $this->requireLogin( 'requiredlogintext' ); ``` which never shows up in labs, and for the Special:Newsletter which showed up a message, the message-param was not given ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletters.php#L13 ) ``` $this->requireLogin(); ```","That's strange. For the first two SpecialPage code, we have ( URL ) ``CODE`CODE`CODE``",NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-1,TRUE,"[""That's strange."", 'For the first two SpecialPage code, we have ( URL )\n``CODE`CODE`CODE``']",NA,0,"For the first two SpecialPage code, we have ( URL )\n``CODE`CODE`CODE``",INVESTIGATION AND EXPLORATION,, 20992,Login-needed text isn't displayed for all newsletter-pages,"That's strange. For the first two SpecialPage code, we have ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletterCreate.php#L14 ) ``` $this->requireLogin( 'requiredlogintext' ); ``` which never shows up in labs, and for the Special:Newsletter which showed up a message, the message-param was not given ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletters.php#L13 ) ``` $this->requireLogin(); ```",1435487917,PHID-USER-b3xlpjqyzhcppjoumu63,PHID-TASK-uo5x4miw3tt6q2aggbse,task_subcomment,"That's strange. For the first two SpecialPage code, we have ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletterCreate.php#L14 ) ``` $this->requireLogin( 'requiredlogintext' ); ``` which never shows up in labs, and for the Special:Newsletter which showed up a message, the message-param was not given ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/SpecialNewsletters.php#L13 ) ``` $this->requireLogin(); ```","That's strange. For the first two SpecialPage code, we have ( URL ) ``CODE`CODE`CODE``",NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-1,TRUE,"[""That's strange."", 'For the first two SpecialPage code, we have ( URL )\n``CODE`CODE`CODE``']",NA,0,That's strange.,SOCIAL CONVERSATION,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).,OBSERVED BUG BEHAVIOR,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,Special:NovaInstance shows the instance as ACTIVE.,BUG REPRODUCTION,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,"Tried rebooting it via the web interface, no change.",WORKAROUND,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,"I can ssh to other instances in the same project normally, and the services are running there as well.",OBSERVED BUG BEHAVIOR,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,Could this be an NFS problem?,INVESTIGATION AND EXPLORATION,, 21033,Can't login to catgraph instance,"When trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",1434985744,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_description,"Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``` $ ssh -A jkroll@sylvester.eqiad.wmflabs If you are having access problems, please see:https://labsconsole.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey). ``` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?","Can't login to catgraph instance./n/nWhen trying to ssh to sylvester I get the following: ``CODE`` The catgraph service which should be running there is not reachable either (connection refused). Special:NovaInstance shows the instance as ACTIVE. Tried rebooting it via the web interface, no change. I can ssh to other instances in the same project normally, and the services are running there as well. Could this be an NFS problem?",Needs Triage,90,1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,resolved,TRUE,c3,2,FALSE,FALSE,-2,TRUE,"[""Can't login to catgraph instance."", 'When trying to ssh to sylvester I get the following:\n\n``CODE``\n\nThe catgraph service which should be running there is not reachable either (connection refused).', 'Special:NovaInstance shows the instance as ACTIVE.', 'Tried rebooting it via the web interface, no change.', 'I can ssh to other instances in the same project normally, and the services are running there as well.', 'Could this be an NFS problem?']",TRUE,0,Can't login to catgraph instance.,OBSERVED BUG BEHAVIOR,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,"Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.",INVESTIGATION AND EXPLORATION,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,"Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.",WORKAROUND,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.,SOLUTION USAGE,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly.,CONTRIBUTION AND COMMITMENT,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running.,WORKAROUND,, 21034,Can't login to catgraph instance,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",1434988559,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.","I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly. You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running. Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long. Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment. Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem. Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"[""I've removed role::labsnfs::client and webserver::apache and catgraph_hostmap from the puppet config of that instance in order to allow puppet to run properly."", ""You'll need to restore those classes and rearrange your git branches on the puppet master to get puppet running."", ""Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long."", 'Remember, if puppet runs are failing on an instance, that instance may fall off the internet at any moment.', 'Additionally, I sent an email several weeks ago that specifically described your use case with instructions about how to avoid this specific problem.', 'Please subscribe to labs-l and read the announcements there in order avoid future issues such as this one.']",NA,0,Puppet clearly hadn't run on this instance for many months -- it's a miracle that it's been working this long.,INVESTIGATION AND EXPLORATION,, 21035,Can't login to catgraph instance,"Thanks for the quick response, but I still can't ssh there - same output as before :/",1434986926,PHID-USER-zzbdvschb2zxhrxixhcr,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,"Thanks for the quick response, but I still can't ssh there - same output as before :/","Thanks for the quick response, but I still can't ssh there - same output as before :/",NA,NA,NA,NA,NA,TRUE,c3,2,FALSE,NA,-2,TRUE,"[""Thanks for the quick response, but I still can't ssh there - same output as before :/""]",NA,0,"Thanks for the quick response, but I still can't ssh there - same output as before :/",SOCIAL CONVERSATION,, 21036,Can't login to catgraph instance,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,1434986298,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"['Logins should be fixed now.', ""Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.""]",NA,0,Logins should be fixed now.,TASK PROGRESS,, 21036,Can't login to catgraph instance,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,1434986298,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-t5fuhkrhetszx5h74eys,task_subcomment,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,Logins should be fixed now. Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-2,TRUE,"['Logins should be fixed now.', ""Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.""]",NA,0,Part of this issue was caused by a broken puppet run -- it's very important that you keep your instances with properly running puppet.,INVESTIGATION AND EXPLORATION,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link.",OBSERVED BUG BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.,INVESTIGATION AND EXPLORATION,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"In VisualEditor, these appear identically.",OBSERVED BUG BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.",OBSERVED BUG BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \",OBSERVED BUG BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0," but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.",INVESTIGATION AND EXPLORATION,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,Expected result: VisualEditor should present existing interwiki links as interwiki links.,EXPECTED BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"Maybe the glitch is in what Parsoid provides, or some link normalization code.",INVESTIGATION AND EXPLORATION,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!",OBSERVED BUG BEHAVIOR,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"That's great, so why don't existing interwiki links display and act this way?",INVESTIGATION AND EXPLORATION,, 21479,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link","https://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",1435267655,PHID-USER-gbl4hfak3cfurt3c7skd,PHID-TASK-5gkuyhirmvr5yqrduicj,task_description,"VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nhttps://www.mediawiki.org/wiki/Reading/Web/SWAT_policy?action=edit&oldid=1692782 has both an interwiki [[`labsconsole:SWAT_deploys#Guidelines` | //link text// ]] link and a URL [`https://wikitech.wikimedia.org/wiki/SWAT_deploys#Guidelines` //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows https://wikitech... - click Edit in the link popup and it shows an ""External link"" https://wikitech.. All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the https://wikitech link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.","VisualEditor presents existing interwiki link as external link, indistinguishable from http link./n/nURL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link. In VisualEditor, these appear identically. - external link ""arrow"" icon - click on them and the link popup shows URL - click Edit in the link popup and it shows an ""External link"" URL All of this is wrong for an interwiki link. If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing! If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital 'W' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane. That's great, so why don't existing interwiki links display and act this way? Expected result: VisualEditor should present existing interwiki links as interwiki links. {T51316} is fixed, but this behavior doesn't feel right. Maybe the glitch is in what Parsoid provides, or some link normalization code.",High,80,1435604174,PHID-USER-ydswvwhh5pm4lshahjje,duplicate,TRUE,c3,2,FALSE,FALSE,-1,TRUE,"['VisualEditor presents existing interwiki link as external link, indistinguishable from http link.', 'URL has both an interwiki [[CODE | //link text// ]] link and a URL [CODE //link text//] link.', 'In VisualEditor, these appear identically.', '- external link ""arrow"" icon\n- click on them and the link popup shows URL\n- click Edit in the link popup and it shows an ""External link"" URL\n\nAll of this is wrong for an interwiki link.', ""If you're editing in order to change https: links to interwiki links, or if you're trying to distinguish interwiki link synonyms (such as labsconsole/wikitech or en/w/wikipedia) it's very confusing!"", 'If I switch the Link dialog to ""Search pages"" pane and change the URL link to interwiki wikitech:SWAT_deploys#Guidelines , then it appears without an external link icon, and the link popup shows **W**ikitech:SWAT_deploys#Guidelines (capital \'W\' but close enough), and if I Edit I see the interwiki link I entered in the ""Search pages"" pane.', ""That's great, so why don't existing interwiki links display and act this way?"", 'Expected result: VisualEditor should present existing interwiki links as interwiki links.', ""{T51316} is fixed, but this behavior doesn't feel right."", 'Maybe the glitch is in what Parsoid provides, or some link normalization code.']",TRUE,0,"{T51316} is fixed, but this behavior doesn't feel right.",TASK PROGRESS,X, 21739,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?,NA,1442130864,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-3gn6zg24xw5de3ptutz7,task_description,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?./n/nnan,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?./n/nnan,Medium,50,1443112395,PHID-USER-v7bwpq3rs3zdxegibdbh,resolved,TRUE,c3,3,TRUE,TRUE,10,TRUE,"[""[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'."", 'Perhaps no aliases are defined for it?.']",TRUE,0,Perhaps no aliases are defined for it?.,INVESTIGATION AND EXPLORATION,, 21739,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?,NA,1442130864,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-3gn6zg24xw5de3ptutz7,task_description,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?./n/nnan,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?./n/nnan,Medium,50,1443112395,PHID-USER-v7bwpq3rs3zdxegibdbh,resolved,TRUE,c3,3,TRUE,TRUE,10,TRUE,"[""[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'."", 'Perhaps no aliases are defined for it?.']",TRUE,0,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'.,OBSERVED BUG BEHAVIOR,, 21740,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?,"Change 239154 merged by jenkins-bot: Fix alias not working [[https://gerrit.wikimedia.org/r/239154]]",1443112192,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3gn6zg24xw5de3ptutz7,task_subcomment,"Change 239154 merged by jenkins-bot: Fix alias not working [[https://gerrit.wikimedia.org/r/239154]]","Change 239154 merged by jenkins-bot: Fix alias not working [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,12,TRUE,['Change 239154 merged by jenkins-bot:\nFix alias not working\n\n[[GERRIT_URL]]'],NA,0,Change 239154 merged by jenkins-bot:\nFix alias not working\n\n[[GERRIT_URL]],TASK PROGRESS,, 21741,[TwitterLogin] PHP Notice: Did not find alias for special page 'TwitterLogin'. Perhaps no aliases are defined for it?,"Change 239154 had a related patch set uploaded (by Paladox): Fix alias not working [[https://gerrit.wikimedia.org/r/239154]] ",1442513241,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3gn6zg24xw5de3ptutz7,task_subcomment,"Change 239154 had a related patch set uploaded (by Paladox): Fix alias not working [[https://gerrit.wikimedia.org/r/239154]] ","Change 239154 had a related patch set uploaded (by Paladox): Fix alias not working [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,11,TRUE,['Change 239154 had a related patch set uploaded (by Paladox):\nFix alias not working\n\n[[GERRIT_URL]]'],NA,0,Change 239154 had a related patch set uploaded (by Paladox):\nFix alias not working\n\n[[GERRIT_URL]],TASK PROGRESS,, 21993,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)","URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``` Original exception: [2e097b64] /wiki/index.php/Special:WhatLinksHere/Media:Shellfish.jpg MWException from line 56 of C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php: MWNamespace::getTalk does not make any sense for given namespace -2 Backtrace: #0 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php(109): MWNamespace::isMethodValidFor(integer, string) #1 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\Title.php(1332): MWNamespace::getTalk(integer) #2 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(247): Title->getTalkPage() #3 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(172): Skin->preloadExistence() #4 C:\Users\Alan\Documents\Programming\MediaWiki\Vector\SkinVector.php(47): Skin->initPage(OutputPage) #5 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\SkinTemplate.php(233): SkinVector->initPage(OutputPage) #6 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\OutputPage.php(2318): SkinTemplate->outputPage() #7 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(685): OutputPage->output() #8 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(474): MediaWiki->main() #9 C:\Users\Alan\Documents\Programming\MediaWiki\core\index.php(41): MediaWiki->run() #10 {main} ``` Was fixed in rSVN103450 (November 2011) but has regressed. What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following: ``` MediaWiki internal error.<br /> <br /> Exception caught inside exception handler.<br /> <br /> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br /> ```",1441017868,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-k2cl36nqtint7t7psyjp,task_description,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)./n/nURLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``` Original exception: [2e097b64] /wiki/index.php/Special:WhatLinksHere/Media:Shellfish.jpg MWException from line 56 of C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php: MWNamespace::getTalk does not make any sense for given namespace -2 Backtrace: #0 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php(109): MWNamespace::isMethodValidFor(integer, string) #1 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\Title.php(1332): MWNamespace::getTalk(integer) #2 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(247): Title->getTalkPage() #3 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(172): Skin->preloadExistence() #4 C:\Users\Alan\Documents\Programming\MediaWiki\Vector\SkinVector.php(47): Skin->initPage(OutputPage) #5 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\SkinTemplate.php(233): SkinVector->initPage(OutputPage) #6 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\OutputPage.php(2318): SkinTemplate->outputPage() #7 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(685): OutputPage->output() #8 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(474): MediaWiki->main() #9 C:\Users\Alan\Documents\Programming\MediaWiki\core\index.php(41): MediaWiki->run() #10 {main} ``` Was fixed in rSVN103450 (November 2011) but has regressed. What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following: ``` MediaWiki internal error.<br /> <br /> Exception caught inside exception handler.<br /> <br /> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br /> ```","Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)./n/nURLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``CODE`CODE`CODE``",Medium,50,1442540812,PHID-USER-sx63fwaih5kjt7bz4u6z,resolved,TRUE,c3,3,TRUE,TRUE,8,TRUE,"['Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500).', 'URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error:\n\n``CODE`CODE`CODE``']",TRUE,0,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500).",OBSERVED BUG BEHAVIOR,, 21993,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)","URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``` Original exception: [2e097b64] /wiki/index.php/Special:WhatLinksHere/Media:Shellfish.jpg MWException from line 56 of C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php: MWNamespace::getTalk does not make any sense for given namespace -2 Backtrace: #0 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php(109): MWNamespace::isMethodValidFor(integer, string) #1 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\Title.php(1332): MWNamespace::getTalk(integer) #2 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(247): Title->getTalkPage() #3 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(172): Skin->preloadExistence() #4 C:\Users\Alan\Documents\Programming\MediaWiki\Vector\SkinVector.php(47): Skin->initPage(OutputPage) #5 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\SkinTemplate.php(233): SkinVector->initPage(OutputPage) #6 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\OutputPage.php(2318): SkinTemplate->outputPage() #7 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(685): OutputPage->output() #8 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(474): MediaWiki->main() #9 C:\Users\Alan\Documents\Programming\MediaWiki\core\index.php(41): MediaWiki->run() #10 {main} ``` Was fixed in rSVN103450 (November 2011) but has regressed. What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following: ``` MediaWiki internal error.<br /> <br /> Exception caught inside exception handler.<br /> <br /> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br /> ```",1441017868,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-k2cl36nqtint7t7psyjp,task_description,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)./n/nURLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``` Original exception: [2e097b64] /wiki/index.php/Special:WhatLinksHere/Media:Shellfish.jpg MWException from line 56 of C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php: MWNamespace::getTalk does not make any sense for given namespace -2 Backtrace: #0 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MWNamespace.php(109): MWNamespace::isMethodValidFor(integer, string) #1 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\Title.php(1332): MWNamespace::getTalk(integer) #2 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(247): Title->getTalkPage() #3 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\Skin.php(172): Skin->preloadExistence() #4 C:\Users\Alan\Documents\Programming\MediaWiki\Vector\SkinVector.php(47): Skin->initPage(OutputPage) #5 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\skins\SkinTemplate.php(233): SkinVector->initPage(OutputPage) #6 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\OutputPage.php(2318): SkinTemplate->outputPage() #7 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(685): OutputPage->output() #8 C:\Users\Alan\Documents\Programming\MediaWiki\core\includes\MediaWiki.php(474): MediaWiki->main() #9 C:\Users\Alan\Documents\Programming\MediaWiki\core\index.php(41): MediaWiki->run() #10 {main} ``` Was fixed in rSVN103450 (November 2011) but has regressed. What is interesting is that on WMF sites, this doesn't show the usual ""Wikimedia Foundation error"" page, but instead shows a quasi-plain text response of a kind that I have never seen before: https://www.mediawiki.org/wiki/Special:WhatLinksHere/Media:Wiki.png The HTML source of the returned page is exactly the following: ``` MediaWiki internal error.<br /> <br /> Exception caught inside exception handler.<br /> <br /> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br /> ```","Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)./n/nURLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error: ``CODE`CODE`CODE``",Medium,50,1442540812,PHID-USER-sx63fwaih5kjt7bz4u6z,resolved,TRUE,c3,3,TRUE,TRUE,8,TRUE,"['Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500).', 'URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error:\n\n``CODE`CODE`CODE``']",TRUE,0,URLs of the form Special:WhatLinksHere/Media:Shellfish.jpg fail with the following error:\n\n``CODE`CODE`CODE``,OBSERVED BUG BEHAVIOR,, 21994,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)","Change 238775 merged by jenkins-bot: Extend Title check in Skin for titles without associated titles [[https://gerrit.wikimedia.org/r/238775]]",1442540356,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-k2cl36nqtint7t7psyjp,task_subcomment,"Change 238775 merged by jenkins-bot: Extend Title check in Skin for titles without associated titles [[https://gerrit.wikimedia.org/r/238775]]","Change 238775 merged by jenkins-bot: Extend Title check in Skin for titles without associated titles [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,11,TRUE,['Change 238775 merged by jenkins-bot:\nExtend Title check in Skin for titles without associated titles\n\n[[GERRIT_URL]]'],NA,0,Change 238775 merged by jenkins-bot:\nExtend Title check in Skin for titles without associated titles\n\n[[GERRIT_URL]],TASK PROGRESS,, 21995,"Special:WhatLinksHere with ""Media"" namespace URLs throws an exception (HTTP 500)","Change 238775 had a related patch set uploaded (by Florianschmidtwelzow): Extend Title check in Skin for titles without associated titles [[https://gerrit.wikimedia.org/r/238775]] ",1442418844,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-k2cl36nqtint7t7psyjp,task_subcomment,"Change 238775 had a related patch set uploaded (by Florianschmidtwelzow): Extend Title check in Skin for titles without associated titles [[https://gerrit.wikimedia.org/r/238775]] ","Change 238775 had a related patch set uploaded (by Florianschmidtwelzow): Extend Title check in Skin for titles without associated titles [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,10,TRUE,['Change 238775 had a related patch set uploaded (by Florianschmidtwelzow):\nExtend Title check in Skin for titles without associated titles\n\n[[GERRIT_URL]]'],NA,0,Change 238775 had a related patch set uploaded (by Florianschmidtwelzow):\nExtend Title check in Skin for titles without associated titles\n\n[[GERRIT_URL]],TASK PROGRESS,, 22071,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully","When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",1440090479,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-a7mss4tywb4mpegtivkg,task_description,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.","ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",Medium,50,1440117166,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['ocsp updater: handle openssl ""trylater"" and similar more-gracefully.', ""When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step."", 'OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.']",TRUE,0,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully.",OBSERVED BUG BEHAVIOR,, 22071,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully","When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",1440090479,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-a7mss4tywb4mpegtivkg,task_description,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.","ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",Medium,50,1440117166,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['ocsp updater: handle openssl ""trylater"" and similar more-gracefully.', ""When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step."", 'OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.']",TRUE,0,"OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",EXPECTED BEHAVIOR,, 22071,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully","When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",1440090479,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-a7mss4tywb4mpegtivkg,task_description,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.","ocsp updater: handle openssl ""trylater"" and similar more-gracefully./n/nWhen the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step. OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.",Medium,50,1440117166,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,3,TRUE,TRUE,7,TRUE,"['ocsp updater: handle openssl ""trylater"" and similar more-gracefully.', ""When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step."", 'OpenSSL is partly to blame here for returning exit status zero in these cases (IMHO), but either way we should deal with these cases properly and error out immediately instead of proceeding with further validation checks that are destined to fail.']",TRUE,0,"When the ocsp updater script runs into certain openssl error-responses, it's confused as to what exactly the problem is and doesn't fail until a much later step.",OBSERVED BUG BEHAVIOR,, 22072,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully","Change 232873 merged by BBlack: update-ocsp: refactor validation, check cert life [[https://gerrit.wikimedia.org/r/232873]]",1440116122,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-a7mss4tywb4mpegtivkg,task_subcomment,"Change 232873 merged by BBlack: update-ocsp: refactor validation, check cert life [[https://gerrit.wikimedia.org/r/232873]]","Change 232873 merged by BBlack: update-ocsp: refactor validation, check cert life [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,"['Change 232873 merged by BBlack:\nupdate-ocsp: refactor validation, check cert life\n\n[[GERRIT_URL]]']",NA,0,"Change 232873 merged by BBlack:\nupdate-ocsp: refactor validation, check cert life\n\n[[GERRIT_URL]]",TASK PROGRESS,, 22073,"ocsp updater: handle openssl ""trylater"" and similar more-gracefully","Change 232873 had a related patch set uploaded (by BBlack): update-ocsp: refactor validation, check cert life [[https://gerrit.wikimedia.org/r/232873]] ",1440115452,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-a7mss4tywb4mpegtivkg,task_subcomment,"Change 232873 had a related patch set uploaded (by BBlack): update-ocsp: refactor validation, check cert life [[https://gerrit.wikimedia.org/r/232873]] ","Change 232873 had a related patch set uploaded (by BBlack): update-ocsp: refactor validation, check cert life [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,7,TRUE,"['Change 232873 had a related patch set uploaded (by BBlack):\nupdate-ocsp: refactor validation, check cert life\n\n[[GERRIT_URL]]']",NA,0,"Change 232873 had a related patch set uploaded (by BBlack):\nupdate-ocsp: refactor validation, check cert life\n\n[[GERRIT_URL]]",TASK PROGRESS,, 22379,Install composer on tools-login,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",1436077644,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_description,"Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.","Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",Medium,50,1444853289,PHID-USER-muirnivxp5hzppn2a3z7,resolved,TRUE,c3,3,TRUE,FALSE,0,TRUE,"['Install composer on tools-login.', 'This makes installation of web services written in PHP a lot easier since right now one can\'t do ""git clone .."" followed by ""composer install"".', '""npm"", for example, is installed.', 'Would be nice to have composer as well.']",FALSE,0,Install composer on tools-login.,EXPECTED BEHAVIOR,, 22379,Install composer on tools-login,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",1436077644,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_description,"Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.","Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",Medium,50,1444853289,PHID-USER-muirnivxp5hzppn2a3z7,resolved,TRUE,c3,3,TRUE,FALSE,0,TRUE,"['Install composer on tools-login.', 'This makes installation of web services written in PHP a lot easier since right now one can\'t do ""git clone .."" followed by ""composer install"".', '""npm"", for example, is installed.', 'Would be nice to have composer as well.']",FALSE,0,This makes installation of web services written in PHP a lot easier since right now one can\,MOTIVATION,, 22379,Install composer on tools-login,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",1436077644,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_description,"Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.","Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",Medium,50,1444853289,PHID-USER-muirnivxp5hzppn2a3z7,resolved,TRUE,c3,3,TRUE,FALSE,0,TRUE,"['Install composer on tools-login.', 'This makes installation of web services written in PHP a lot easier since right now one can\'t do ""git clone .."" followed by ""composer install"".', '""npm"", for example, is installed.', 'Would be nice to have composer as well.']",FALSE,0,git clone ..,NA,, 22379,Install composer on tools-login,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",1436077644,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_description,"Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.","Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",Medium,50,1444853289,PHID-USER-muirnivxp5hzppn2a3z7,resolved,TRUE,c3,3,TRUE,FALSE,0,TRUE,"['Install composer on tools-login.', 'This makes installation of web services written in PHP a lot easier since right now one can\'t do ""git clone .."" followed by ""composer install"".', '""npm"", for example, is installed.', 'Would be nice to have composer as well.']",FALSE,0,composer install,NA,, 22379,Install composer on tools-login,"This makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",1436077644,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_description,"Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.","Install composer on tools-login./n/nThis makes installation of web services written in PHP a lot easier since right now one can't do ""git clone .."" followed by ""composer install"". ""npm"", for example, is installed. Would be nice to have composer as well.",Medium,50,1444853289,PHID-USER-muirnivxp5hzppn2a3z7,resolved,TRUE,c3,3,TRUE,FALSE,0,TRUE,"['Install composer on tools-login.', 'This makes installation of web services written in PHP a lot easier since right now one can\'t do ""git clone .."" followed by ""composer install"".', '""npm"", for example, is installed.', 'Would be nice to have composer as well.']",FALSE,0,npm,NA,, 22380,Install composer on tools-login,"``` Notice: /Stage[main]/Toollabs::Composer/File[/srv/composer]/ensure: created Notice: /Stage[main]/Toollabs::Composer/Git::Clone[composer]/Exec[git_clone_composer]/returns: executed successfully Notice: /Stage[main]/Toollabs::Composer/File[/usr/local/bin/composer]/ensure: created ``` ``` valhallasw@tools-bastion-01:~$ composer --version Composer version @package_branch_alias_version@ (@package_version@) @release_date@ ``` uuuuh. According to the git log it's version `1.0.0-alpha10`.",1444853289,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"``` Notice: /Stage[main]/Toollabs::Composer/File[/srv/composer]/ensure: created Notice: /Stage[main]/Toollabs::Composer/Git::Clone[composer]/Exec[git_clone_composer]/returns: executed successfully Notice: /Stage[main]/Toollabs::Composer/File[/usr/local/bin/composer]/ensure: created ``` ``` valhallasw@tools-bastion-01:~$ composer --version Composer version @package_branch_alias_version@ (@package_version@) @release_date@ ``` uuuuh. According to the git log it's version `1.0.0-alpha10`.",``CODE`CODE`CODE`CODE1.0.0-alpha10`.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,14,TRUE,['``CODE`CODE`CODE`CODE1.0.0-alpha10`.'],NA,0,``CODE`CODE`CODE`CODE1.0.0-alpha10`.,BUG REPRODUCTION,, 22381,Install composer on tools-login,"Change 246072 merged by Yuvipanda: toollabs: add composer to dev hosts [[https://gerrit.wikimedia.org/r/246072]]",1444853023,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Change 246072 merged by Yuvipanda: toollabs: add composer to dev hosts [[https://gerrit.wikimedia.org/r/246072]]","Change 246072 merged by Yuvipanda: toollabs: add composer to dev hosts [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,14,TRUE,['Change 246072 merged by Yuvipanda:\ntoollabs: add composer to dev hosts\n\n[[GERRIT_URL]]'],NA,0,Change 246072 merged by Yuvipanda:\ntoollabs: add composer to dev hosts\n\n[[GERRIT_URL]],TASK PROGRESS,, 22382,Install composer on tools-login,"Change 246072 had a related patch set uploaded (by Merlijn van Deen): toollabs: add composer to dev hosts [[https://gerrit.wikimedia.org/r/246072]] ",1444767371,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Change 246072 had a related patch set uploaded (by Merlijn van Deen): toollabs: add composer to dev hosts [[https://gerrit.wikimedia.org/r/246072]] ","Change 246072 had a related patch set uploaded (by Merlijn van Deen): toollabs: add composer to dev hosts [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,14,TRUE,['Change 246072 had a related patch set uploaded (by Merlijn van Deen):\ntoollabs: add composer to dev hosts\n\n[[GERRIT_URL]]'],NA,0,Change 246072 had a related patch set uploaded (by Merlijn van Deen):\ntoollabs: add composer to dev hosts\n\n[[GERRIT_URL]],TASK PROGRESS,, 22383,Install composer on tools-login,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,1443230068,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"[""Let's just do the git checkout + symlink option via puppet?"", 'We can make it a composer::install class or something and include it in both tools and integration']",NA,0,We can make it a composer::install class or something and include it in both tools and integration,SOLUTION DISCUSSION,, 22383,Install composer on tools-login,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,1443230068,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"[""Let's just do the git checkout + symlink option via puppet?"", 'We can make it a composer::install class or something and include it in both tools and integration']",NA,0,Let's just do the git checkout + symlink option via puppet?,SOLUTION DISCUSSION,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,A few things I tried.,CONTRIBUTION AND COMMITMENT,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,"- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \",INVESTIGATION AND EXPLORATION,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,", ""*(//",NA,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,"s/)."", ""*//",NA,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,"t seem to work at all?"", ",SOCIAL CONVERSATION,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ",INVESTIGATION AND EXPLORATION,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,"\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ",WORKAROUND,, 22384,Install composer on tools-login,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",1443087883,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"A few things I tried. - building an fpm package from the integration/composer repo works: https://gerrit.wikimedia.org/r/#/c/240451/ - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log for @hashar: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x http://http.debian.net/debian/pool/main/j/jsonlint/jsonlint_1.3.1-2.dsc - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x http://http.debian.net/debian/pool/main/p/php-cli-prompt/php-cli-prompt_1.0.0+dfsg-1.dsc - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x http://http.debian.net/debian/pool/main/c/composer/composer_1.0.0~alpha10+20150602-1.dsc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.","A few things I tried. - building an fpm package from the integration/composer repo works: URL - but might not be an improvement over just using git co, unless we can automate it - backporting is more of an issue Backporting log forSCREEN_NAME: - sudo apt-get install devscripts debian-keyring equivs jsonlint: - dget -x URL - cd jsonlint - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - sudo mk-build-deps --install --remove # installs lots of stuff after hacking the debian/rules, changing the version parsing to | sed 's/.*(//' | sed 's/).*//') - fakeroot debian/rules binary works, but - dpkg-buildpackage -us -uc fails - After rm bin/jsonlint-php, I can build (but of course not sign). But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes! Good. (this is after ca. 50 minutes of fiddling...) php-cli-prompt: - dget -x URL - cd php-cli-prompt_..etc - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - debuild worked immediately. json-schema: same sed issue, but works with the same hack composer: - dget -x URL - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport"" - build requires jsonlint, fun fun fun. - sudo mk-build-deps --install --remove doesn't seem to work at all? - manually installing seems to work - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well? This took me > 1 hour, so I gave up at this point.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,12,TRUE,"['A few things I tried.', '- building an fpm package from the integration/composer repo works: URL\n - but might not be an improvement over just using git co, unless we can automate it\n\n - backporting is more of an issue\n\nBackporting log forSCREEN_NAME:\n - sudo apt-get install devscripts debian-keyring equivs\n\njsonlint:\n - dget -x URL\n - cd jsonlint\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - sudo mk-build-deps --install --remove # installs lots of stuff\n\nafter hacking the debian/rules, changing the version parsing to \n | sed \'s/.', ""*(//' | sed 's/)."", ""*//')\n \n- fakeroot debian/rules binary\n\nworks, but \n\n- dpkg-buildpackage -us -uc\n\nfails\n\n- After rm bin/jsonlint-php, I can build (but of course not sign)."", 'But lintian jsonlint_1.3.1-2~toollabs1+1_all.deb passes!', 'Good.', '(this is after ca.', '50 minutes of fiddling...)\n\nphp-cli-prompt:\n\n- dget -x URL\n - cd php-cli-prompt_..etc\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - debuild\n\nworked immediately.', 'json-schema: same sed issue, but works with the same hack\n\ncomposer:\n - dget -x URL\n - dch --local ~toollabs+ --distribution jessie-toollabs ""Backport""\n - build requires jsonlint, fun fun fun.', ""- sudo mk-build-deps --install --remove doesn't seem to work at all?"", '- manually installing seems to work\n - but it requires php-symfony-console >= 2.4 and jessie bundles 2.3, so we have to backport and install those as well?', 'This took me > 1 hour, so I gave up at this point.']",NA,0,"\n - build requires jsonlint, fun fun fun.', ",INVESTIGATION AND EXPLORATION,, 22385,Install composer on tools-login,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ",1442999775,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ","After discussing withSCREEN_NAME andSCREEN_NAME: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See URL and URL for current usage. ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,11,TRUE,"['After discussing withSCREEN_NAME andSCREEN_NAME:\n\n - backporting the package to precise and trusty is probably difficult.', '- to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer)\n\nWe could use the latter method for tool labs as well.', 'See URL and URL for current usage.']",NA,0,After discussing withSCREEN_NAME andSCREEN_NAME:\n\n - backporting the package to precise and trusty is probably difficult.,SOLUTION DISCUSSION,, 22385,Install composer on tools-login,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ",1442999775,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ","After discussing withSCREEN_NAME andSCREEN_NAME: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See URL and URL for current usage. ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,11,TRUE,"['After discussing withSCREEN_NAME andSCREEN_NAME:\n\n - backporting the package to precise and trusty is probably difficult.', '- to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer)\n\nWe could use the latter method for tool labs as well.', 'See URL and URL for current usage.']",NA,0,"- to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer)\n\nWe could use the latter method for tool labs as well.",SOLUTION DISCUSSION,, 22385,Install composer on tools-login,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ",1442999775,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"After discussing with @joe and @hashar: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, https://github.com/wikimedia/integration-composer is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See https://github.com/wikimedia/operations-puppet/blob/00c433345214115e5a5b05eb6d83eedabfbf7110/modules/contint/manifests/slave-scripts.pp#L29 and https://github.com/wikimedia/operations-puppet/blob/acacf97e2df962fef83487a461f3559fa07e4d6f/modules/extdist/manifests/init.pp#L74 for current usage. ","After discussing withSCREEN_NAME andSCREEN_NAME: - backporting the package to precise and trusty is probably difficult. - to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer) We could use the latter method for tool labs as well. See URL and URL for current usage. ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,11,TRUE,"['After discussing withSCREEN_NAME andSCREEN_NAME:\n\n - backporting the package to precise and trusty is probably difficult.', '- to solve the issue on the integration cluster, URL is used (git checkout, then use /srv/deployment/integration/composer/vendor/bin/composer)\n\nWe could use the latter method for tool labs as well.', 'See URL and URL for current usage.']",NA,0,See URL and URL for current usage.,SOLUTION USAGE,, 22386,Install composer on tools-login,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ``` Now composer is available to e.g. ```lang=sh (mytool at tools-login in ~)$ cd my-repo (mytool at tools-login in ~/my-repo)$ composer install --no-dev ``` ",1442094127,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ``` Now composer is available to e.g. ```lang=sh (mytool at tools-login in ~)$ cd my-repo (mytool at tools-login in ~/my-repo)$ composer install --no-dev ``` ","Work around: ``CODE`CODE`CODE`` ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,10,TRUE,['Work around:\n\n``CODE`CODE`CODE``'],NA,0,Work around:\n\n``CODE`CODE`CODE``,WORKAROUND,, 22387,Install composer on tools-login,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ``` Now composer is available to e.g. ```lang=sh (tool on tools-login)$ cd my-repo (tool on tools-login)$ composer install --no-dev ``` ",1441668524,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ``` Now composer is available to e.g. ```lang=sh (tool on tools-login)$ cd my-repo (tool on tools-login)$ composer install --no-dev ``` ","Work around: ``CODE`CODE`CODE`` ",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,9,TRUE,['Work around:\n\n``CODE`CODE`CODE``'],NA,0,Work around:\n\n``CODE`CODE`CODE``,WORKAROUND,, 22388,Install composer on tools-login,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ```",1441668466,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer ```","Work around: ``CODE``",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,9,TRUE,['Work around:\n\n``CODE``'],NA,0,Work around:\n\n``CODE``,WORKAROUND,, 22389,Install composer on tools-login,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",1441668458,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer","Work-around: ```lang=sh $ ssh tools-login $ become mytool # URL $ mkdir bin $ curl -sS URL | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,9,TRUE,"['Work-around:\n```lang=sh\n$ ssh tools-login\n$ become mytool\n# URL\n$ mkdir bin\n$ curl -sS URL | php -- --install-dir=bin --filename=composer\n# Now installed in ~/bin/composer\n# Make sure your bash PATH includes ""$HOME/bin"".', 'Set in .bashrc if needed.', '$ which composer\n# /data/project/:tool/bin/composer']",NA,0,"Work-around:\n```lang=sh\n$ ssh tools-login\n$ become mytool\n# URL\n$ mkdir bin\n$ curl -sS URL | php -- --install-dir=bin --filename=composer\n# Now installed in ~/bin/composer\n# Make sure your bash PATH includes ""$HOME/bin"".",WORKAROUND,, 22389,Install composer on tools-login,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",1441668458,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer","Work-around: ```lang=sh $ ssh tools-login $ become mytool # URL $ mkdir bin $ curl -sS URL | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,9,TRUE,"['Work-around:\n```lang=sh\n$ ssh tools-login\n$ become mytool\n# URL\n$ mkdir bin\n$ curl -sS URL | php -- --install-dir=bin --filename=composer\n# Now installed in ~/bin/composer\n# Make sure your bash PATH includes ""$HOME/bin"".', 'Set in .bashrc if needed.', '$ which composer\n# /data/project/:tool/bin/composer']",NA,0,Set in .bashrc if needed.,WORKAROUND,, 22389,Install composer on tools-login,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",1441668458,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,"Work-around: ```lang=sh $ ssh tools-login $ become mytool # https://getcomposer.org/download/ $ mkdir bin $ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer","Work-around: ```lang=sh $ ssh tools-login $ become mytool # URL $ mkdir bin $ curl -sS URL | php -- --install-dir=bin --filename=composer # Now installed in ~/bin/composer # Make sure your bash PATH includes ""$HOME/bin"". Set in .bashrc if needed. $ which composer # /data/project/:tool/bin/composer",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,9,TRUE,"['Work-around:\n```lang=sh\n$ ssh tools-login\n$ become mytool\n# URL\n$ mkdir bin\n$ curl -sS URL | php -- --install-dir=bin --filename=composer\n# Now installed in ~/bin/composer\n# Make sure your bash PATH includes ""$HOME/bin"".', 'Set in .bashrc if needed.', '$ which composer\n# /data/project/:tool/bin/composer']",NA,0,$ which composer\n# /data/project/:tool/bin/composer,INVESTIGATION AND EXPLORATION,, 22390,Install composer on tools-login,There's a package in debian-unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714118,1436094239,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,There's a package in debian-unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714118,There's a package in debian-unstable: URL,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,0,TRUE,"[""There's a package in debian-unstable: URL""]",NA,0,There's a package in debian-unstable: URL,ISSUE CONTENT MANAGEMENT,, 22391,Install composer on tools-login,There's an package in debian-unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714118,1436094221,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,There's an package in debian-unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714118,There's an package in debian-unstable: URL,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,0,TRUE,"[""There's an package in debian-unstable: URL""]",NA,0,There's an package in debian-unstable: URL,ISSUE CONTENT MANAGEMENT,, 22392,Install composer on tools-login,Is there a Debian package for it?,1436093816,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-mib56lmwmjd226wmav6y,task_subcomment,Is there a Debian package for it?,Is there a Debian package for it?,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,0,TRUE,['Is there a Debian package for it?'],NA,0,Is there a Debian package for it?,INVESTIGATION AND EXPLORATION,, 22695,replace tendril.wikimedia.org's sha1 cert with sha256,"Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate",1432928583,PHID-USER-xy6c3ul27f336aaedx2d,PHID-TASK-z2ax7hrjllplsah4gtps,task_description,"replace tendril.wikimedia.org's sha1 cert with sha256./n/nTracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate","replace tendril.wikimedia.org's sha1 cert with sha256./n/nTracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate",Medium,50,1433275859,PHID-USER-fo56wm4wxiwpoofn2xdu,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"[""replace tendril.wikimedia.org's sha1 cert with sha256."", ""Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps:\n\n[x] - reissue certificate in sha256\n[x] - update configuration to use new certificate\n[x] - push changes live\n[ ] - revoke old sha1 certificate""]",TRUE,0,replace tendril.wikimedia.org's sha1 cert with sha256.,EXPECTED BEHAVIOR,, 22695,replace tendril.wikimedia.org's sha1 cert with sha256,"Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate",1432928583,PHID-USER-xy6c3ul27f336aaedx2d,PHID-TASK-z2ax7hrjllplsah4gtps,task_description,"replace tendril.wikimedia.org's sha1 cert with sha256./n/nTracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate","replace tendril.wikimedia.org's sha1 cert with sha256./n/nTracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps: [x] - reissue certificate in sha256 [x] - update configuration to use new certificate [x] - push changes live [ ] - revoke old sha1 certificate",Medium,50,1433275859,PHID-USER-fo56wm4wxiwpoofn2xdu,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"[""replace tendril.wikimedia.org's sha1 cert with sha256."", ""Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps:\n\n[x] - reissue certificate in sha256\n[x] - update configuration to use new certificate\n[x] - push changes live\n[ ] - revoke old sha1 certificate""]",TRUE,0,"Tracking task to replace tendril.wikimedia.org's sha1 cert with sha256, in multiple steps:\n\n[x] - reissue certificate in sha256\n[x] - update configuration to use new certificate\n[x] - push changes live\n[ ] - revoke old sha1 certificate",ISSUE CONTENT MANAGEMENT,, 22696,replace tendril.wikimedia.org's sha1 cert with sha256,"also was: https://gerrit.wikimedia.org/r/#/c/215403/ replaced now: Signature algorithm SHA256withRSA https://www.ssllabs.com/ssltest/analyze.html?d=tendril.wikimedia.org",1433275859,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-z2ax7hrjllplsah4gtps,task_subcomment,"also was: https://gerrit.wikimedia.org/r/#/c/215403/ replaced now: Signature algorithm SHA256withRSA https://www.ssllabs.com/ssltest/analyze.html?d=tendril.wikimedia.org","also was: URL replaced now: Signature algorithm SHA256withRSA URL",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,['also was: URL\n\nreplaced now:\nSignature algorithm \tSHA256withRSA\n\nURL'],NA,0,also was: URL\n\nreplaced now:\nSignature algorithm \tSHA256withRSA\n\nURL,ISSUE CONTENT MANAGEMENT,, 22697,replace tendril.wikimedia.org's sha1 cert with sha256,"Change 214692 merged by Dzahn: replace tendril.wikimedia.org's sha1 cert with sha256 [[https://gerrit.wikimedia.org/r/214692]]",1433275169,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-z2ax7hrjllplsah4gtps,task_subcomment,"Change 214692 merged by Dzahn: replace tendril.wikimedia.org's sha1 cert with sha256 [[https://gerrit.wikimedia.org/r/214692]]","Change 214692 merged by Dzahn: replace tendril.wikimedia.org's sha1 cert with sha256 [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,"[""Change 214692 merged by Dzahn:\nreplace tendril.wikimedia.org's sha1 cert with sha256\n\n[[GERRIT_URL]]""]",NA,0,Change 214692 merged by Dzahn:\nreplace tendril.wikimedia.org's sha1 cert with sha256\n\n[[GERRIT_URL]],TASK PROGRESS,, 22698,replace tendril.wikimedia.org's sha1 cert with sha256,"Change 214692 had a related patch set uploaded (by RobH): replace tendril.wikimedia.org's sha1 cert with sha256 [[https://gerrit.wikimedia.org/r/214692]] ",1432928605,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-z2ax7hrjllplsah4gtps,task_subcomment,"Change 214692 had a related patch set uploaded (by RobH): replace tendril.wikimedia.org's sha1 cert with sha256 [[https://gerrit.wikimedia.org/r/214692]] ","Change 214692 had a related patch set uploaded (by RobH): replace tendril.wikimedia.org's sha1 cert with sha256 [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,"[""Change 214692 had a related patch set uploaded (by RobH):\nreplace tendril.wikimedia.org's sha1 cert with sha256\n\n[[GERRIT_URL]]""]",NA,0,Change 214692 had a related patch set uploaded (by RobH):\nreplace tendril.wikimedia.org's sha1 cert with sha256\n\n[[GERRIT_URL]],TASK PROGRESS,, 22728,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Almost every login: ``` PHP Notice: Undefined variable: status in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 PHP Fatal error: Call to a member function isGood() on a non-object in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 ``` Not a big issue, but it floods log files.",1432304324,PHID-USER-6dmbpidylyt4dzsxzjg4,PHID-TASK-4ok7hmihyelt2skxvmru,task_description,"Undefined variable: status in specials/SpecialOAuthLogin.php on line 53./n/nAlmost every login: ``` PHP Notice: Undefined variable: status in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 PHP Fatal error: Call to a member function isGood() on a non-object in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 ``` Not a big issue, but it floods log files.","Undefined variable: status in specials/SpecialOAuthLogin.php on line 53./n/nAlmost every login: ``CODE`` Not a big issue, but it floods log files.",Medium,50,1432764669,PHID-USER-doeppszazlm3r7xah4il,resolved,TRUE,c3,1,TRUE,FALSE,-6,TRUE,"['Undefined variable: status in specials/SpecialOAuthLogin.php on line 53.', 'Almost every login:\n``CODE``\nNot a big issue, but it floods log files.']",TRUE,0,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53.,OBSERVED BUG BEHAVIOR,, 22728,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Almost every login: ``` PHP Notice: Undefined variable: status in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 PHP Fatal error: Call to a member function isGood() on a non-object in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 ``` Not a big issue, but it floods log files.",1432304324,PHID-USER-6dmbpidylyt4dzsxzjg4,PHID-TASK-4ok7hmihyelt2skxvmru,task_description,"Undefined variable: status in specials/SpecialOAuthLogin.php on line 53./n/nAlmost every login: ``` PHP Notice: Undefined variable: status in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 PHP Fatal error: Call to a member function isGood() on a non-object in /data/project/commonsarchive/public_html/w/extensions/OAuthAuthentication/specials/SpecialOAuthLogin.php on line 53 PHP Stack trace: PHP 1. {main}() /data/project/commonsarchive/public_html/w/index.php:0 PHP 2. MediaWiki->run() /data/project/commonsarchive/public_html/w/index.php:46 PHP 3. MediaWiki->main() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:435 PHP 4. MediaWiki->performRequest() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:584 PHP 5. SpecialPageFactory::executePath() /data/project/commonsarchive/public_html/w/includes/MediaWiki.php:275 PHP 6. SpecialPage->run() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPageFactory.php:584 PHP 7. MediaWiki\Extensions\OAuthAuthentication\SpecialOAuthLogin->execute() /data/project/commonsarchive/public_html/w/includes/specialpage/SpecialPage.php:363 ``` Not a big issue, but it floods log files.","Undefined variable: status in specials/SpecialOAuthLogin.php on line 53./n/nAlmost every login: ``CODE`` Not a big issue, but it floods log files.",Medium,50,1432764669,PHID-USER-doeppszazlm3r7xah4il,resolved,TRUE,c3,1,TRUE,FALSE,-6,TRUE,"['Undefined variable: status in specials/SpecialOAuthLogin.php on line 53.', 'Almost every login:\n``CODE``\nNot a big issue, but it floods log files.']",TRUE,0,"Almost every login:\n``CODE``\nNot a big issue, but it floods log files.",OBSERVED BUG BEHAVIOR,, 22729,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Change 214090 abandoned by CSteipp: Remove $status causing warning Reason: Duplicate of https://gerrit.wikimedia.org/r/#/c/212785/ [[https://gerrit.wikimedia.org/r/214090]]",1432754341,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4ok7hmihyelt2skxvmru,task_subcomment,"Change 214090 abandoned by CSteipp: Remove $status causing warning Reason: Duplicate of https://gerrit.wikimedia.org/r/#/c/212785/ [[https://gerrit.wikimedia.org/r/214090]]","Change 214090 abandoned by CSteipp: Remove $status causing warning Reason: Duplicate of URL [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-6,TRUE,['Change 214090 abandoned by CSteipp:\nRemove $status causing warning\n\nReason:\nDuplicate of URL\n\n[[GERRIT_URL]]'],NA,0,Change 214090 abandoned by CSteipp:\nRemove $status causing warning\n\nReason:\nDuplicate of URL\n\n[[GERRIT_URL]],TASK PROGRESS,, 22730,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Change 212785 merged by jenkins-bot: SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[https://gerrit.wikimedia.org/r/212785]]",1432754330,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4ok7hmihyelt2skxvmru,task_subcomment,"Change 212785 merged by jenkins-bot: SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[https://gerrit.wikimedia.org/r/212785]]","Change 212785 merged by jenkins-bot: SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-6,TRUE,['Change 212785 merged by jenkins-bot:\nSpecialOAuthLogin.php/init: Removing !$status->isGood() error handling\n\n[[GERRIT_URL]]'],NA,0,Change 212785 merged by jenkins-bot:\nSpecialOAuthLogin.php/init: Removing !$status->isGood() error handling\n\n[[GERRIT_URL]],TASK PROGRESS,, 22731,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Change 214090 had a related patch set uploaded (by CSteipp): Remove $status causing warning [[https://gerrit.wikimedia.org/r/214090]] ",1432754266,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4ok7hmihyelt2skxvmru,task_subcomment,"Change 214090 had a related patch set uploaded (by CSteipp): Remove $status causing warning [[https://gerrit.wikimedia.org/r/214090]] ","Change 214090 had a related patch set uploaded (by CSteipp): Remove $status causing warning [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-6,TRUE,['Change 214090 had a related patch set uploaded (by CSteipp):\nRemove $status causing warning\n\n[[GERRIT_URL]]'],NA,0,Change 214090 had a related patch set uploaded (by CSteipp):\nRemove $status causing warning\n\n[[GERRIT_URL]],TASK PROGRESS,, 22732,Undefined variable: status in specials/SpecialOAuthLogin.php on line 53,"Change 212785 had a related patch set uploaded (by Gerrit Patch Uploader): SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[https://gerrit.wikimedia.org/r/212785]] ",1432305296,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-4ok7hmihyelt2skxvmru,task_subcomment,"Change 212785 had a related patch set uploaded (by Gerrit Patch Uploader): SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[https://gerrit.wikimedia.org/r/212785]] ","Change 212785 had a related patch set uploaded (by Gerrit Patch Uploader): SpecialOAuthLogin.php/init: Removing !$status->isGood() error handling [[GERRIT_URL]] ",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-6,TRUE,['Change 212785 had a related patch set uploaded (by Gerrit Patch Uploader):\nSpecialOAuthLogin.php/init: Removing !$status->isGood() error handling\n\n[[GERRIT_URL]]'],NA,0,Change 212785 had a related patch set uploaded (by Gerrit Patch Uploader):\nSpecialOAuthLogin.php/init: Removing !$status->isGood() error handling\n\n[[GERRIT_URL]],TASK PROGRESS,, 23122,Make sure new webservice tool accepts lighttpd overrides,"Current webservice allows php overrides via ``` if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then ``` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",1433947884,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-sp5dimdulsrqhop3bcbr,task_description,"Make sure new webservice tool accepts lighttpd overrides./n/nCurrent webservice allows php overrides via ``` if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then ``` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.","Make sure new webservice tool accepts lighttpd overrides./n/nCurrent webservice allows php overrides via ``CODE`` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",Low,25,1467721812,PHID-USER-2nnm76h4ykalvvref2ye,resolved,TRUE,c3,1,TRUE,FALSE,-4,TRUE,"['Make sure new webservice tool accepts lighttpd overrides.', 'Current webservice allows php overrides via\n\n``CODE``\n\nThis is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.']",FALSE,0,Make sure new webservice tool accepts lighttpd overrides.,EXPECTED BEHAVIOR,, 23122,Make sure new webservice tool accepts lighttpd overrides,"Current webservice allows php overrides via ``` if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then ``` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",1433947884,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-sp5dimdulsrqhop3bcbr,task_description,"Make sure new webservice tool accepts lighttpd overrides./n/nCurrent webservice allows php overrides via ``` if [ ! -r $home/.lighttpd.conf ] || [[ ! $(cat ""$home/.lighttpd.conf"" | grep -P '^(?:[ \t]*fastcgi.server[ \t\+\(=]+"".php""|#no-default-php)') ]]; then ``` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.","Make sure new webservice tool accepts lighttpd overrides./n/nCurrent webservice allows php overrides via ``CODE`` This is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",Low,25,1467721812,PHID-USER-2nnm76h4ykalvvref2ye,resolved,TRUE,c3,1,TRUE,FALSE,-4,TRUE,"['Make sure new webservice tool accepts lighttpd overrides.', 'Current webservice allows php overrides via\n\n``CODE``\n\nThis is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.']",FALSE,0,"Current webservice allows php overrides via\n\n``CODE``\n\nThis is currently undocumented (see T101994), but maybe in use, so should be supported by the new webservice tool.",EXPECTED BEHAVIOR,, 23123,Make sure new webservice tool accepts lighttpd overrides,It does!,1467721812,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,It does!,It does!,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,52,TRUE,['It does!'],NA,0,It does!,SOCIAL CONVERSATION,, 23124,Make sure new webservice tool accepts lighttpd overrides,"oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.",1433948609,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.","oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover."", ""There's a task for that somewhere, let me find it.""]",NA,0,"oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover.",CONTRIBUTION AND COMMITMENT,, 23124,Make sure new webservice tool accepts lighttpd overrides,"oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.",1433948609,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.","oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover. There's a task for that somewhere, let me find it.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""oh, and for type==lighttpd-plain - because it's undocumented I'm just going to move them over manually when doing the switchover."", ""There's a task for that somewhere, let me find it.""]",NA,0,"There's a task for that somewhere, let me find it.",ISSUE CONTENT MANAGEMENT,, 23125,Make sure new webservice tool accepts lighttpd overrides,"https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py#L100 reads it and appends it to itself, no?",1433948582,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py#L100 reads it and appends it to itself, no?","URL reads it and appends it to itself, no?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"['URL reads it and appends it to itself, no?']",NA,0,"URL reads it and appends it to itself, no?",INVESTIGATION AND EXPLORATION,, 23126,Make sure new webservice tool accepts lighttpd overrides,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",1433948524,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain","No, it doesn't. These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""No, it doesn't."", 'These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag.', ""I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain""]",NA,0,"These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag.",INVESTIGATION AND EXPLORATION,, 23126,Make sure new webservice tool accepts lighttpd overrides,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",1433948524,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain","No, it doesn't. These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""No, it doesn't."", 'These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag.', ""I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain""]",NA,0,"No, it doesn't.",SOCIAL CONVERSATION,, 23126,Make sure new webservice tool accepts lighttpd overrides,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",1433948524,PHID-USER-muirnivxp5hzppn2a3z7,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,"No, it doesn't. These are switches based on content .lighttpd.conf, while https://github.com/wikimedia/operations-software-tools-webservice/blob/master/toollabs/webservice/services/lighttpdwebservice.py only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain","No, it doesn't. These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag. I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"[""No, it doesn't."", 'These are switches based on content .lighttpd.conf, while URL only switches based on a command-line flag.', ""I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain""]",NA,0,"I don't think we have to support the flags, but we should detect them and error out with a message to use --type=lighttpd-plain",SOLUTION DISCUSSION,, 23127,Make sure new webservice tool accepts lighttpd overrides,It already is! And the new webservice tool isn't deployed yet.,1433947928,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,It already is! And the new webservice tool isn't deployed yet.,It already is! And the new webservice tool isn't deployed yet.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"['It already is!', ""And the new webservice tool isn't deployed yet.""]",NA,0,It already is!,SOCIAL CONVERSATION,, 23127,Make sure new webservice tool accepts lighttpd overrides,It already is! And the new webservice tool isn't deployed yet.,1433947928,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-sp5dimdulsrqhop3bcbr,task_subcomment,It already is! And the new webservice tool isn't deployed yet.,It already is! And the new webservice tool isn't deployed yet.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-4,TRUE,"['It already is!', ""And the new webservice tool isn't deployed yet.""]",NA,0,And the new webservice tool isn't deployed yet.,FUTURE PLANS,, 23499,revoke/delete bugzilla ssl certs,"this is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",1425943168,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-obn6jccjdmq62xb6va4c,task_description,"revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ","revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ URL , URL - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on URL ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",Needs Triage,90,1426094541,PHID-USER-xy6c3ul27f336aaedx2d,resolved,TRUE,c3,1,TRUE,FALSE,-17,TRUE,"['revoke/delete bugzilla ssl certs.', 'this is a ticket to revoke the SSL cert:\n\nbugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\n- revoke with the CA / vendor\n- ~~delete cert from public repo~~ URL , URL\n- ~~delete the matching .key from private repo~~ done by dzahn\n- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn\n\n(once RobH commented on URL\n\n""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")', 'so this is intended to include that and the other steps, i will strike out what i have done.']",TRUE,0,revoke/delete bugzilla ssl certs.,EXPECTED BEHAVIOR,, 23499,revoke/delete bugzilla ssl certs,"this is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",1425943168,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-obn6jccjdmq62xb6va4c,task_description,"revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ","revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ URL , URL - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on URL ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",Needs Triage,90,1426094541,PHID-USER-xy6c3ul27f336aaedx2d,resolved,TRUE,c3,1,TRUE,FALSE,-17,TRUE,"['revoke/delete bugzilla ssl certs.', 'this is a ticket to revoke the SSL cert:\n\nbugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\n- revoke with the CA / vendor\n- ~~delete cert from public repo~~ URL , URL\n- ~~delete the matching .key from private repo~~ done by dzahn\n- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn\n\n(once RobH commented on URL\n\n""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")', 'so this is intended to include that and the other steps, i will strike out what i have done.']",TRUE,0,"this is a ticket to revoke the SSL cert:\n\nbugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\n- revoke with the CA / vendor\n- ~~delete cert from public repo~~ URL , URL\n- ~~delete the matching .key from private repo~~ done by dzahn\n- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn\n\n(once RobH commented on URL\n\n""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")",ISSUE CONTENT MANAGEMENT,, 23499,revoke/delete bugzilla ssl certs,"this is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",1425943168,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-obn6jccjdmq62xb6va4c,task_description,"revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ https://gerrit.wikimedia.org/r/#/c/195307/ , https://gerrit.wikimedia.org/r/#/c/195804/ - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on https://gerrit.wikimedia.org/r/#/c/164001/ ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ","revoke/delete bugzilla ssl certs./n/nthis is a ticket to revoke the SSL cert: bugzilla.wikimedia.org bug-attachment.wikimedia.org - revoke with the CA / vendor - ~~delete cert from public repo~~ URL , URL - ~~delete the matching .key from private repo~~ done by dzahn - ~~rm/shred cert and key on servers it is installed on~~ done by dzahn (once RobH commented on URL ""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."") so this is intended to include that and the other steps, i will strike out what i have done. ",Needs Triage,90,1426094541,PHID-USER-xy6c3ul27f336aaedx2d,resolved,TRUE,c3,1,TRUE,FALSE,-17,TRUE,"['revoke/delete bugzilla ssl certs.', 'this is a ticket to revoke the SSL cert:\n\nbugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\n- revoke with the CA / vendor\n- ~~delete cert from public repo~~ URL , URL\n- ~~delete the matching .key from private repo~~ done by dzahn\n- ~~rm/shred cert and key on servers it is installed on~~ done by dzahn\n\n(once RobH commented on URL\n\n""anytime we delete a certificate, please make an independent core-ops ticket to invalidate the certificate on the provider level, and assign said ticket to me."")', 'so this is intended to include that and the other steps, i will strike out what i have done.']",TRUE,0,"so this is intended to include that and the other steps, i will strike out what i have done.",ISSUE CONTENT MANAGEMENT,, 23500,revoke/delete bugzilla ssl certs,"certs revoked from rapidssl: bugzilla.wikimedia.org bug-attachment.wikimedia.org resolving task",1426094541,PHID-USER-xy6c3ul27f336aaedx2d,PHID-TASK-obn6jccjdmq62xb6va4c,task_subcomment,"certs revoked from rapidssl: bugzilla.wikimedia.org bug-attachment.wikimedia.org resolving task","certs revoked from rapidssl: bugzilla.wikimedia.org bug-attachment.wikimedia.org resolving task",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-17,TRUE,['certs revoked from rapidssl: bugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\nresolving task'],NA,0,certs revoked from rapidssl: bugzilla.wikimedia.org\nbug-attachment.wikimedia.org\n\nresolving task,TASK PROGRESS,, 23841,Shop homepage on HTTPS loads insecure content,"https://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]",1427322534,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_description,"Shop homepage on HTTPS loads insecure content./n/nhttps://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]","Shop homepage on HTTPS loads insecure content./n/nURL a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET URL [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org * GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]",High,80,1449353758,PHID-USER-sai77mtxmpqnm6pycyvz,resolved,TRUE,c3,1,FALSE,FALSE,-15,TRUE,"['Shop homepage on HTTPS loads insecure content.', 'URL\n\na 404 and a mixed content warning.', ""mixed content causes the site's lock icon on location bar to indicate site is insecure."", '* GET URL [HTTP/1.1 404 Not Found 416ms]\n* Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org\n* GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]']",FALSE,0,Shop homepage on HTTPS loads insecure content.,OBSERVED BUG BEHAVIOR,, 23841,Shop homepage on HTTPS loads insecure content,"https://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]",1427322534,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_description,"Shop homepage on HTTPS loads insecure content./n/nhttps://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]","Shop homepage on HTTPS loads insecure content./n/nURL a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET URL [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org * GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]",High,80,1449353758,PHID-USER-sai77mtxmpqnm6pycyvz,resolved,TRUE,c3,1,FALSE,FALSE,-15,TRUE,"['Shop homepage on HTTPS loads insecure content.', 'URL\n\na 404 and a mixed content warning.', ""mixed content causes the site's lock icon on location bar to indicate site is insecure."", '* GET URL [HTTP/1.1 404 Not Found 416ms]\n* Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org\n* GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]']",FALSE,0,URL\n\na 404 and a mixed content warning.,OBSERVED BUG BEHAVIOR,, 23841,Shop homepage on HTTPS loads insecure content,"https://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]",1427322534,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_description,"Shop homepage on HTTPS loads insecure content./n/nhttps://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]","Shop homepage on HTTPS loads insecure content./n/nURL a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET URL [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org * GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]",High,80,1449353758,PHID-USER-sai77mtxmpqnm6pycyvz,resolved,TRUE,c3,1,FALSE,FALSE,-15,TRUE,"['Shop homepage on HTTPS loads insecure content.', 'URL\n\na 404 and a mixed content warning.', ""mixed content causes the site's lock icon on location bar to indicate site is insecure."", '* GET URL [HTTP/1.1 404 Not Found 416ms]\n* Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org\n* GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]']",FALSE,0,"* GET URL [HTTP/1.1 404 Not Found 416ms]\n* Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org\n* GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]",OBSERVED BUG BEHAVIOR,, 23841,Shop homepage on HTTPS loads insecure content,"https://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]",1427322534,PHID-USER-7ey733eainlhx5xqp4d3,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_description,"Shop homepage on HTTPS loads insecure content./n/nhttps://shop.wikimedia.org/ a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET https://cdn.shopify.com/s/files/1/0160/7500/t/13/assets/option_selection.js [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg"" [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Learn More]] shop.wikimedia.org * GET http://cdn.shopify.com/s/files/1/0713/7997/t/2/assets/icon-shopping-basket.svg [[https://developer.mozilla.org/en-US/docs/Security/MixedContent|Mixed Content]][HTTP/1.1 200 OK 334ms]","Shop homepage on HTTPS loads insecure content./n/nURL a 404 and a mixed content warning. mixed content causes the site's lock icon on location bar to indicate site is insecure. * GET URL [HTTP/1.1 404 Not Found 416ms] * Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org * GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]",High,80,1449353758,PHID-USER-sai77mtxmpqnm6pycyvz,resolved,TRUE,c3,1,FALSE,FALSE,-15,TRUE,"['Shop homepage on HTTPS loads insecure content.', 'URL\n\na 404 and a mixed content warning.', ""mixed content causes the site's lock icon on location bar to indicate site is insecure."", '* GET URL [HTTP/1.1 404 Not Found 416ms]\n* Loading mixed (insecure) display content on a secure page ""URL [[URL More]] shop.wikimedia.org\n* GET URL [[URL Content]][HTTP/1.1 200 OK 334ms]']",FALSE,0,mixed content causes the site's lock icon on location bar to indicate site is insecure.,OBSERVED BUG BEHAVIOR,, 23842,Shop homepage on HTTPS loads insecure content,The 404 and mixed content warnings have been resolved.,1449353758,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_subcomment,The 404 and mixed content warnings have been resolved.,The 404 and mixed content warnings have been resolved.,NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,22,TRUE,['The 404 and mixed content warnings have been resolved.'],NA,0,The 404 and mixed content warnings have been resolved.,TASK PROGRESS,, 23843,Shop homepage on HTTPS loads insecure content,https://store.wikimedia.org/pages/privacy-policy is terribly generic. Why isn't shopify mentioned anywhere in the website?,1430201919,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_subcomment,https://store.wikimedia.org/pages/privacy-policy is terribly generic. Why isn't shopify mentioned anywhere in the website?,URL is terribly generic. Why isn't shopify mentioned anywhere in the website?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['URL is terribly generic.', ""Why isn't shopify mentioned anywhere in the website?""]",NA,0,URL is terribly generic.,INVESTIGATION AND EXPLORATION,, 23843,Shop homepage on HTTPS loads insecure content,https://store.wikimedia.org/pages/privacy-policy is terribly generic. Why isn't shopify mentioned anywhere in the website?,1430201919,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_subcomment,https://store.wikimedia.org/pages/privacy-policy is terribly generic. Why isn't shopify mentioned anywhere in the website?,URL is terribly generic. Why isn't shopify mentioned anywhere in the website?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-10,TRUE,"['URL is terribly generic.', ""Why isn't shopify mentioned anywhere in the website?""]",NA,0,Why isn't shopify mentioned anywhere in the website?,INVESTIGATION AND EXPLORATION,, 23844,Shop homepage on HTTPS loads insecure content,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,1428422282,PHID-USER-grgqimagqq3ankitlzm5,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_subcomment,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-13,TRUE,"['I have fixed the insecure content warning.', 'Not sure what option_selection.js is meant to be though.']",NA,0,I have fixed the insecure content warning.,TASK PROGRESS,, 23844,Shop homepage on HTTPS loads insecure content,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,1428422282,PHID-USER-grgqimagqq3ankitlzm5,PHID-TASK-hpz4xgn77fh5oaljj5vi,task_subcomment,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,I have fixed the insecure content warning. Not sure what option_selection.js is meant to be though.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-13,TRUE,"['I have fixed the insecure content warning.', 'Not sure what option_selection.js is meant to be though.']",NA,0,Not sure what option_selection.js is meant to be though.,INVESTIGATION AND EXPLORATION,, 24737,AttributeError: 'HttpRequest' object has no attribute '_join',"D:\Py\rewrite>`pwb.py interwiki -async -cleanup -whenneeded:5 -family:wiktionary -untranslated -lang:ast -subcats:Lling<6E><67>es -array:300` ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 937, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 679, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 256, in request r = fetch(baseuri, *args, **kwargs) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 353, in fetch request._join() # wait for it AttributeError: 'HttpRequest' object has no attribute '_join' WARNING: Waiting 5 seconds before retrying. ``` after replacing bot with latest nightly: ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 983, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 711, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 248, in request baseuri = site.base_url(uri) File ""D:\Py\rewrite\pywikibot\site.py"", line 641, in __getattr__ % (self.__class__.__name__, attr)) AttributeError: APISite instance has no attribute 'base_url' WARNING: Waiting 5 seconds before retrying. ```",1421137807,PHID-USER-wwnv7nzuscfuc2xfjwbq,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_description,"AttributeError: 'HttpRequest' object has no attribute '_join'./n/nD:\Py\rewrite>`pwb.py interwiki -async -cleanup -whenneeded:5 -family:wiktionary -untranslated -lang:ast -subcats:Lling<6E><67>es -array:300` ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 937, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 679, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 256, in request r = fetch(baseuri, *args, **kwargs) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 353, in fetch request._join() # wait for it AttributeError: 'HttpRequest' object has no attribute '_join' WARNING: Waiting 5 seconds before retrying. ``` after replacing bot with latest nightly: ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 983, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 711, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 248, in request baseuri = site.base_url(uri) File ""D:\Py\rewrite\pywikibot\site.py"", line 641, in __getattr__ % (self.__class__.__name__, attr)) AttributeError: APISite instance has no attribute 'base_url' WARNING: Waiting 5 seconds before retrying. ```","AttributeError: 'HttpRequest' object has no attribute '_join'./n/nD:\Py\rewrite>CODE ``CODE`CODE`CODE``",Medium,50,1421220620,PHID-USER-wwnv7nzuscfuc2xfjwbq,invalid,TRUE,c3,1,TRUE,TRUE,-25,TRUE,"[""AttributeError: 'HttpRequest' object has no attribute '_join'."", 'D:\\Py\\rewrite>CODE\n\n``CODE`CODE`CODE``']",TRUE,0,D:\\Py\\rewrite>CODE\n\n``CODE`CODE`CODE``,NA,, 24737,AttributeError: 'HttpRequest' object has no attribute '_join',"D:\Py\rewrite>`pwb.py interwiki -async -cleanup -whenneeded:5 -family:wiktionary -untranslated -lang:ast -subcats:Lling<6E><67>es -array:300` ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 937, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 679, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 256, in request r = fetch(baseuri, *args, **kwargs) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 353, in fetch request._join() # wait for it AttributeError: 'HttpRequest' object has no attribute '_join' WARNING: Waiting 5 seconds before retrying. ``` after replacing bot with latest nightly: ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 983, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 711, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 248, in request baseuri = site.base_url(uri) File ""D:\Py\rewrite\pywikibot\site.py"", line 641, in __getattr__ % (self.__class__.__name__, attr)) AttributeError: APISite instance has no attribute 'base_url' WARNING: Waiting 5 seconds before retrying. ```",1421137807,PHID-USER-wwnv7nzuscfuc2xfjwbq,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_description,"AttributeError: 'HttpRequest' object has no attribute '_join'./n/nD:\Py\rewrite>`pwb.py interwiki -async -cleanup -whenneeded:5 -family:wiktionary -untranslated -lang:ast -subcats:Lling<6E><67>es -array:300` ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 937, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 679, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 256, in request r = fetch(baseuri, *args, **kwargs) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 353, in fetch request._join() # wait for it AttributeError: 'HttpRequest' object has no attribute '_join' WARNING: Waiting 5 seconds before retrying. ``` after replacing bot with latest nightly: ``` ERROR: Traceback (most recent call last): File ""D:\Py\rewrite\pywikibot\data\api.py"", line 983, in submit headers=headers, body=body) File ""D:\Py\rewrite\pywikibot\tools.py"", line 711, in wrapper return obj(*__args, **__kw) File ""D:\Py\rewrite\pywikibot\comms\http.py"", line 248, in request baseuri = site.base_url(uri) File ""D:\Py\rewrite\pywikibot\site.py"", line 641, in __getattr__ % (self.__class__.__name__, attr)) AttributeError: APISite instance has no attribute 'base_url' WARNING: Waiting 5 seconds before retrying. ```","AttributeError: 'HttpRequest' object has no attribute '_join'./n/nD:\Py\rewrite>CODE ``CODE`CODE`CODE``",Medium,50,1421220620,PHID-USER-wwnv7nzuscfuc2xfjwbq,invalid,TRUE,c3,1,TRUE,TRUE,-25,TRUE,"[""AttributeError: 'HttpRequest' object has no attribute '_join'."", 'D:\\Py\\rewrite>CODE\n\n``CODE`CODE`CODE``']",TRUE,0,AttributeError: 'HttpRequest' object has no attribute '_join'.,OBSERVED BUG BEHAVIOR,, 24738,AttributeError: 'HttpRequest' object has no attribute '_join',"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",1421324878,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.","Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-24,TRUE,"[""Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does."", ""Maybe it doesn't change files which are currently write protected or so."", 'But even then why should threadedhttp.py and site.py be write protected.']",NA,0,But even then why should threadedhttp.py and site.py be write protected.,INVESTIGATION AND EXPLORATION,, 24738,AttributeError: 'HttpRequest' object has no attribute '_join',"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",1421324878,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.","Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-24,TRUE,"[""Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does."", ""Maybe it doesn't change files which are currently write protected or so."", 'But even then why should threadedhttp.py and site.py be write protected.']",NA,0,"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does.",INVESTIGATION AND EXPLORATION,, 24738,AttributeError: 'HttpRequest' object has no attribute '_join',"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",1421324878,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.","Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does. Maybe it doesn't change files which are currently write protected or so. But even then why should threadedhttp.py and site.py be write protected.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-24,TRUE,"[""Okay that is indeed then strange behavior, but I'm not sure what <20><><EFBFBD>SVN Update<74><65><EFBFBD> actually does."", ""Maybe it doesn't change files which are currently write protected or so."", 'But even then why should threadedhttp.py and site.py be write protected.']",NA,0,Maybe it doesn't change files which are currently write protected or so.,INVESTIGATION AND EXPLORATION,, 24739,AttributeError: 'HttpRequest' object has no attribute '_join',">>! In T86621#975389, @XZise wrote: > I know a clear installation worked, but that looked like you didn't update the `pywikibot/family.py` file. I made ""SVN Update"" as usually. ",1421237390,PHID-USER-wwnv7nzuscfuc2xfjwbq,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,">>! In T86621#975389, @XZise wrote: > I know a clear installation worked, but that looked like you didn't update the `pywikibot/family.py` file. I made ""SVN Update"" as usually. ","QUOTE QUOTE I made ""SVN Update"" as usually. ",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"['QUOTE\nQUOTE\n\nI made ""SVN Update"" as usually.']",NA,0,"QUOTE\nQUOTE\n\nI made ""SVN Update"" as usually.",SOCIAL CONVERSATION,, 24740,AttributeError: 'HttpRequest' object has no attribute '_join',"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.",1421233647,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.","And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like CODE got updated and that is in the same directory as CODE. The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"[""And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there."", 'Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half?', 'Although it looks like CODE got updated and that is in the same directory as CODE.', 'The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.']",NA,0,Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half?,INVESTIGATION AND EXPLORATION,, 24740,AttributeError: 'HttpRequest' object has no attribute '_join',"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.",1421233647,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.","And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like CODE got updated and that is in the same directory as CODE. The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"[""And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there."", 'Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half?', 'Although it looks like CODE got updated and that is in the same directory as CODE.', 'The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.']",NA,0,Although it looks like CODE got updated and that is in the same directory as CODE.,INVESTIGATION AND EXPLORATION,, 24740,AttributeError: 'HttpRequest' object has no attribute '_join',"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.",1421233647,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.","And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like CODE got updated and that is in the same directory as CODE. The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"[""And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there."", 'Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half?', 'Although it looks like CODE got updated and that is in the same directory as CODE.', 'The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.']",NA,0,"The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.",INVESTIGATION AND EXPLORATION,, 24740,AttributeError: 'HttpRequest' object has no attribute '_join',"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.",1421233647,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"And the first traceback indicates that `pywikibot.comms.threadedhttp` wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like `pywikibot.comms.http` got updated and that is in the same directory as `threadedhttp`. The second one is also related to a `http` module which is newer than other files, so maybe it was the other way around that only `http` was updated.","And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there. Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half? Although it looks like CODE got updated and that is in the same directory as CODE. The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"[""And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there."", 'Maybe on a previous update you accidentally moved the contents into the wrong directory and it only updated half?', 'Although it looks like CODE got updated and that is in the same directory as CODE.', 'The second one is also related to a CODE module which is newer than other files, so maybe it was the other way around that only CODE was updated.']",NA,0,"And the first traceback indicates that CODE wasn't updated, because I'm pretty certain that tests would've failed immediately if the first bug were actually in there.",INVESTIGATION AND EXPLORATION,, 24741,AttributeError: 'HttpRequest' object has no attribute '_join',"I know a clear installation worked, but that looked like you didn't update the `pywikibot/family.py` file.",1421227013,PHID-USER-7fndkemmavweiht5ybfd,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,"I know a clear installation worked, but that looked like you didn't update the `pywikibot/family.py` file.","I know a clear installation worked, but that looked like you didn't update the CODE file.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"[""I know a clear installation worked, but that looked like you didn't update the CODE file.""]",NA,0,"I know a clear installation worked, but that looked like you didn't update the CODE file.",INVESTIGATION AND EXPLORATION,, 24742,AttributeError: 'HttpRequest' object has no attribute '_join',clear isntalation of bot solved it.,1421220620,PHID-USER-wwnv7nzuscfuc2xfjwbq,PHID-TASK-fj2lt64pw4hakqjbxpfj,task_subcomment,clear isntalation of bot solved it.,clear isntalation of bot solved it.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,['clear isntalation of bot solved it.'],NA,0,clear isntalation of bot solved it.,WORKAROUND,, 24945,Make DynamicProxy be able to proxy back to non-http protocols,"Currently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",1418982881,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_description,"Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.","Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",Low,25,1467722731,PHID-USER-2nnm76h4ykalvvref2ye,declined,TRUE,c3,1,TRUE,TRUE,-28,TRUE,"['Make DynamicProxy be able to proxy back to non-http protocols.', 'Currently it assumes that you are proxying back to http:// and adds it if it is not found.', 'Make it possible to proxy back to other protocols, like fastcgi or uwsgi.']",FALSE,0,Make DynamicProxy be able to proxy back to non-http protocols.,EXPECTED BEHAVIOR,, 24945,Make DynamicProxy be able to proxy back to non-http protocols,"Currently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",1418982881,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_description,"Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.","Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",Low,25,1467722731,PHID-USER-2nnm76h4ykalvvref2ye,declined,TRUE,c3,1,TRUE,TRUE,-28,TRUE,"['Make DynamicProxy be able to proxy back to non-http protocols.', 'Currently it assumes that you are proxying back to http:// and adds it if it is not found.', 'Make it possible to proxy back to other protocols, like fastcgi or uwsgi.']",FALSE,0,Currently it assumes that you are proxying back to http:// and adds it if it is not found.,OBSERVED BUG BEHAVIOR,, 24945,Make DynamicProxy be able to proxy back to non-http protocols,"Currently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",1418982881,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_description,"Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.","Make DynamicProxy be able to proxy back to non-http protocols./n/nCurrently it assumes that you are proxying back to http:// and adds it if it is not found. Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",Low,25,1467722731,PHID-USER-2nnm76h4ykalvvref2ye,declined,TRUE,c3,1,TRUE,TRUE,-28,TRUE,"['Make DynamicProxy be able to proxy back to non-http protocols.', 'Currently it assumes that you are proxying back to http:// and adds it if it is not found.', 'Make it possible to proxy back to other protocols, like fastcgi or uwsgi.']",FALSE,0,"Make it possible to proxy back to other protocols, like fastcgi or uwsgi.",EXPECTED BEHAVIOR,, 24946,Make DynamicProxy be able to proxy back to non-http protocols,"I think any performance advantage will be negated by the additonal complexity, so let's not do this.",1467722731,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"I think any performance advantage will be negated by the additonal complexity, so let's not do this.","I think any performance advantage will be negated by the additonal complexity, so let's not do this.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,52,TRUE,"[""I think any performance advantage will be negated by the additonal complexity, so let's not do this.""]",NA,0,"I think any performance advantage will be negated by the additonal complexity, so let's not do this.",MOTIVATION,, 24947,Make DynamicProxy be able to proxy back to non-http protocols,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",1420807846,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.","Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"['Boo!', 'nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on.', 'This is terrible.']",NA,0,Boo!,SOCIAL CONVERSATION,, 24947,Make DynamicProxy be able to proxy back to non-http protocols,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",1420807846,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.","Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"['Boo!', 'nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on.', 'This is terrible.']",NA,0,"nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on.",INVESTIGATION AND EXPLORATION,, 24947,Make DynamicProxy be able to proxy back to non-http protocols,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",1420807846,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.","Boo! nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on. This is terrible.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-25,TRUE,"['Boo!', 'nginx requires uwsgi_pass, fastcgi_pass, proxy_pass depending on what protocol the origin server is listening on.', 'This is terrible.']",NA,0,This is terrible.,SOCIAL CONVERSATION,, 24948,Make DynamicProxy be able to proxy back to non-http protocols,Yay! :),1419009664,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,Yay! :),Yay! :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-28,TRUE,"['Yay!', ':)']",NA,0,Yay!,SOCIAL CONVERSATION,, 24948,Make DynamicProxy be able to proxy back to non-http protocols,Yay! :),1419009664,PHID-USER-2nnm76h4ykalvvref2ye,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,Yay! :),Yay! :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-28,TRUE,"['Yay!', ':)']",NA,0,:),SOCIAL CONVERSATION,, 24949,Make DynamicProxy be able to proxy back to non-http protocols,"Change 181073 merged by Yuvipanda: tools: Allow origin protocols other than http [[https://gerrit.wikimedia.org/r/181073]]",1419004966,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"Change 181073 merged by Yuvipanda: tools: Allow origin protocols other than http [[https://gerrit.wikimedia.org/r/181073]]","Change 181073 merged by Yuvipanda: tools: Allow origin protocols other than http [[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-28,TRUE,['Change 181073 merged by Yuvipanda:\ntools: Allow origin protocols other than http\n\n[[GERRIT_URL]]'],NA,0,Change 181073 merged by Yuvipanda:\ntools: Allow origin protocols other than http\n\n[[GERRIT_URL]],TASK PROGRESS,, 24950,Make DynamicProxy be able to proxy back to non-http protocols,"Change 181073 had a related patch set uploaded (by Yuvipanda): tools: Allos origin protocols other than http [[https://gerrit.wikimedia.org/r/181073]] #patch-for-review",1419002375,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yorbznbgwmqwd27m6uvq,task_subcomment,"Change 181073 had a related patch set uploaded (by Yuvipanda): tools: Allos origin protocols other than http [[https://gerrit.wikimedia.org/r/181073]] #patch-for-review","Change 181073 had a related patch set uploaded (by Yuvipanda): tools: Allos origin protocols other than http [[GERRIT_URL]] #patch-for-review",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-28,TRUE,['Change 181073 had a related patch set uploaded (by Yuvipanda):\ntools: Allos origin protocols other than http\n\n[[GERRIT_URL]]\n\n#patch-for-review'],NA,0,Change 181073 had a related patch set uploaded (by Yuvipanda):\ntools: Allos origin protocols other than http\n\n[[GERRIT_URL]]\n\n#patch-for-review,TASK PROGRESS,,